Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
FIG. 1 shows a block diagram that illustrates a system 10 including a computer system 11, and an associated Internet 22 connection. Such configuration is typically used for computers (hosts) connected to the Internet 22 and executing a server, or a client (or a combination) software. The computer system 11 may be used as a portable electronic device such as a notebook/laptop computer, a media player (e.g., MP3 based or video player), a desktop computer, a laptop computer, a cellular phone, a Personal Digital Assistant (PDA), an image processing device (e.g., a digital camera or video recorder), any other handheld or fixed location computing devices, or a combination of any of these devices.
Note that while FIG. 1 illustrates various components of the computer system 11, it is not intended to represent any particular architecture or manner of interconnecting the components.
Network computers, handheld computers, cell phones and other data processing systems that have fewer or more components, may also be used. For example, the computer of FIG. 1 may be an Apple Macintosh computer, or a Power Book, or an IBM compatible PC. The computer system 11 may include a bus 13, an interconnect, or other communication mechanism for communicating information, and a processor 12, commonly in the form of an integrated circuit, coupled to the bus 13 for processing information, and for executing the computer executable instructions. The computer system 11 may also include a main memory 15a, such as a Random Access Memory (RAM), or other dynamic storage device, coupled to the bus 13 for storing information and instructions to be executed by the processor 12. The main memory 15a also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 12.
The computer system 11 further includes a Read Only Memory (ROM) 15b (or other non-volatile memory) or other static storage device coupled to the bus 13 for storing static information and instructions for the processor 12. A storage device 15c, that may be a magnetic disk or optical disk, such as a hard disk drive (HDD) for reading from and writing to a hard disk, a magnetic disk drive for reading from and writing to a magnetic disk, and/or an optical disk drive (such as DVD) for reading from and writing to a removable optical disk, is coupled to the bus 13 for storing information and instructions. The hard disk drive, magnetic disk drive, and optical disk drive may be connected to the system bus 13 by a hard disk drive interface, a magnetic disk drive interface, and an optical disk drive interface, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the general-purpose computing devices.
Typically, the computer system 11 includes an Operating System (OS) stored in a non-volatile storage 15b for managing the computer resources and provides the applications and programs with access to the computer resources and interfaces. An operating system commonly processes system data and user input, and responds by allocating and managing tasks and internal system resources, such as controlling and allocating memory, prioritizing system requests, controlling input and output devices, facilitating networking and managing files. Non-limiting examples of operating systems are Microsoft Windows, Mac OS X, and Linux.
The computer system 11 may be coupled via the bus 13 to a display 17, such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), a flat screen monitor, a touch screen monitor or similar means for displaying text and graphical data to a user. The display 17 may be connected via a video adapter for supporting the display. The display 17 allows a user to view, enter, and/or edit information that is relevant to the operation of the system 10. An input device 18, including alphanumeric and other keys, is coupled to the bus 13 for communicating information and command selections to the processor 12. Another type of user input device is a cursor control 18a, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processor 12 and for controlling cursor movement on the display 17. This cursor control 18a typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The computer system 11 may be used for implementing the methods and techniques described herein. According to one embodiment, these methods and techniques are performed by the computer system 11 in response to the processor 12 executing one or more sequences of one or more instructions contained in the main memory 15a. Such instructions may be read into the main memory 15a from another computer-readable medium, such as the storage device 15c. Execution of the sequences of instructions contained in the main memory 15a causes the processor 12 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the arrangement. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “processor” is used herein to include, but not limited to, any integrated circuit or any other electronic device (or collection of electronic devices) capable of performing an operation on at least one instruction, including, without limitation, a microprocessor (μP), a microcontroller (μC), a Digital Signal Processor (DSP), or any combination thereof. A processor, such as the processor 12, may further be a Reduced Instruction Set Core (RISC) processor, a Complex Instruction Set Computing (CISC) microprocessor, a Microcontroller Unit (MCU), or a CISC-based Central Processing Unit (CPU). The hardware of the processor 12 may be integrated onto a single substrate (e.g., silicon “die”), or distributed among two or more substrates. Furthermore, various functional aspects of the processor 12 may be implemented solely as a software (or firmware) associated with the processor 12.
A memory can store computer programs or any other sequence of computer readable instructions, or data, such as files, text, numbers, audio and video, as well as any other form of information represented as a string or structure of bits or bytes. The physical means of storing information may be electrostatic, ferroelectric, magnetic, acoustic, optical, chemical, electronic, electrical, or mechanical. A memory may be in the form of an Integrated Circuit (IC, a.k.a. chip or microchip). Alternatively or in addition, a memory may be in the form of a packaged functional assembly of electronic components (module). Such module may be based on a Printed Circuit Board (PCB) such as PC Card according to Personal Computer Memory Card International Association (PCMCIA) PCMCIA 2.0 standard, or a Single In-line Memory Module (SIMM) or a Dual In-line Memory Module (DIMM), standardized under the JEDEC JESD-21C standard. Further, a memory may be in the form of a separately rigidly enclosed box such as an external Hard-Disk Drive (HDD). A capacity of a memory is commonly featured in bytes (B), where the prefix ‘K’ is used to denote kilo=210=10241=1024, the prefix ‘M’ is used to denote mega=220=10242=1,048,576, the prefix ‘G’ is used to denote Giga=230=10243=1,073,741,824, and the prefix ‘T’ is used to denote tera=240=10244=1,099,511,627,776.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor 12 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 11 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal, and appropriate circuitry may place the data on the bus 13. The bus 13 carries the data to the main memory 15a, from which the processor 12 retrieves and executes the instructions. The instructions received by the main memory 15a may optionally be stored on the storage device 15c either before or after execution by the processor 12.
The computer system 11 commonly includes a communication interface 9 coupled to the bus 13. The communication interface 9 provides a two-way data communication coupling to a network link 8 that is connected to a Local Area Network (LAN) 14. For example, the communication interface 9 may be an Integrated Services Digital Network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another non-limiting example, the communication interface 9 may be a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN. For example, Ethernet-based connection based on IEEE802.3 standard may be used, such as 10/100BaseT, 1000BaseT (gigabit Ethernet), 10 gigabit Ethernet (10 GE or 10 GbE or 10 GigE per IEEE Std. 802.3ae-2002as standard), 40 Gigabit Ethernet (40 GbE), or 100 Gigabit Ethernet (100 GbE as per Ethernet standard IEEE P802.3ba). These technologies are described in Cisco Systems, Inc. Publication number 1-587005-001-3 (6/99), “Internetworking Technologies Handbook”, Chapter 7: “Ethernet Technologies”, pages 7-1 to 7-38, which is incorporated in its entirety for all purposes as if fully set forth herein. In such a case, the communication interface 9 typically includes a LAN transceiver or a modem, such as a Standard Microsystems Corporation (SMSC) LAN91C111 10/100 Ethernet transceiver, described in the Standard Microsystems Corporation (SMSC) data-sheet “LAN91C111 10/100 Non-PCI Ethernet Single Chip MAC+PHY” Data-Sheet, Rev. 15 (Feb. 20, 2004), which is incorporated in its entirety for all purposes as if fully set forth herein.
An Internet Service Provider (ISP) 16 is an organization that provides services for accessing, using, or participating in the Internet 22. The Internet Service Provider 16 may be organized in various forms, such as commercial, community-owned, non-profit, or otherwise privately owned. Internet services, typically provided by ISPs, include Internet access, Internet transit, domain name registration, web hosting, and collocation. Various ISP Structures are described in Chapter 2: “Structural Overview of ISP Networks” of the book entitled: “Guide to Reliable Internet Services and Applications”, by Robert D. Doverspike, K K Ramakrishnan, and Chris Chase, published 2010 (ISBN: 978-1-84882-827-8), which is incorporated in its entirety for all purposes as if fully set forth herein.
A mailbox provider is an organization that provides services for hosting electronic mail domains with access to storage for mailboxes. It allows email servers to send, receive, accept, and store email for end users or other organizations. Internet hosting services provide email, web-hosting, or online storage services. Other services include virtual server, cloud services, or physical server operation. A virtual ISP (VISP) is an ISP that purchases services from another ISP, sometimes called a wholesale ISP in this context, which allows the VISP's customers to access the Internet using services and infrastructure owned and operated by the wholesale ISP. It is akin to mobile virtual network operators and competitive local exchange carriers for voice communications. A Wireless Internet Service Provider (WISP) is an Internet service provider with a network based on wireless networking. Technology may include commonplace Wi-Fi wireless mesh networking, or proprietary equipment designed to operate over open 900 MHz, 2.4 GHz, 4.9, 5.2, 5.4, 5.7, and 5.8 GHz bands or licensed frequencies in the UHF band (including the MMDS frequency band) and LMDS.
ISPs may engage in peering, where multiple ISPs interconnect at peering points or Internet exchange points (IXs), allowing routing of data between each network, without charging one another for the data transmitted—data that would otherwise have passed through a third upstream ISP, incurring charges from the upstream ISP. ISPs requiring no upstream and having only customers (end customers and/or peer ISPs) are referred to as Tier 1 ISPs.
An arrangement 10a of a computer system connected to the Internet 22 is shown in FIG. 2. A computer system or a workstation 7 includes a main unit box 6 with an enclosed motherboard that has the processor 12 and the memories 15a, 15b, and 15c are mounted. The workstation 7 may include a keyboard 2 (corresponding to the input device 18), a printer 4, a computer mouse 3 (corresponding to the cursor control 18a), and a display 5 (corresponding to the display 17). FIG. 2 further illustrates various devices connected via the Internet 22, such as a client device #1 24, a client device #2 24a, a data server #1 23a, a data server #2 23b, and the workstation 7, connected to the Internet 22 over a LAN 14 and via the router or gateway 19 and the ISP 16.
The client device #1 24 and the client device #2 24a may communicate over the Internet 22 for exchanging or obtaining data from the data server #1 23a and the data server #2 23b. In one example, the servers are HTTP servers, sometimes known as web servers. A method describing a more efficient communication over the Internet is described in U.S. Pat. No. 8,560,604 to Shribman et al., entitled: “System and Method for Providing Faster and More Efficient Data Communication” (hereinafter the ‘604 patent’), which is incorporated in its entirety for all purposes as if fully set forth herein. A splitting of a message or a content into slices, and transferring each of the slices over a distinct data path are described in U.S. Patent Application No. 2012/0166582 to Binder entitled: “System and Method for Routing-Based Internet Security”, which is incorporated in its entirety for all purposes as if fully set forth herein.
The term “computer-readable medium” (or “machine-readable medium”) is used herein to include, but not limited to, any medium or any memory, that participates in providing instructions to a processor, (such as the processor 12) for execution, or any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). Such a medium may store computer-executable instructions to be executed by a processing element and/or control logic and data, which is manipulated by a processing element and/or control logic, and may take many forms, including but not limited to, non-volatile medium, volatile medium, and transmission medium. Transmission media includes coaxial cables, copper wire, and fiber optics, including the wires that comprise the bus 13. Transmission media may also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications, or other form of propagating signals (e.g., carrier waves, infrared signals, digital signals, etc.). Common forms of computer-readable media include a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch-cards, paper-tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer may read.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor 12 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 11 can receive the data on the telephone line, using an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry may place the data on the bus 13. The bus 13 carries the data to the main memory 15a, from which the processor 12 retrieves and executes the instructions. The instructions received by the main memory 15a may optionally be stored on the storage device 15c either before or after execution by the processor 12.
The Internet is a global system of interconnected computer networks that use the standardized Internet Protocol Suite (TCP/IP), including Transmission Control Protocol (TCP) and the Internet Protocol (IP), to serve billions of users worldwide. It is a network of networks that consists of millions of private, public, academic, business, and government networks, of local to global scope, that are linked by a broad array of electronic and optical networking technologies. The Internet carries a vast range of information resources and services, such as the interlinked hypertext documents on the World Wide Web (WWW) and the infrastructure to support electronic mail. The Internet backbone refers to the principal data routes between large, strategically interconnected networks and core routers on the Internet. These data routers are hosted by commercial, government, academic, and other high-capacity network centers, the Internet exchange points and network access points that interchange Internet traffic between the countries, continents and across the oceans of the world. Traffic interchange between Internet service providers (often Tier 1 networks) participating in the Internet backbone exchange traffic by privately negotiated interconnection agreements, primarily governed by the principle of settlement-free peering.
The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol suite (IP) described in RFC 675 and RFC 793, and the entire suite is often referred to as TCP/IP. TCP provides reliable, ordered and error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer. Web browsers typically use TCP when they connect to servers on the World Wide Web, and is used to deliver email and transfer files from one location to another. HTTP, HTTPS, SMTP, POP3, IMAP, SSH, FTP, Telnet and a variety of other protocols are encapsulated in TCP. As the transport layer of TCP/IP suite, the TCP provides a communication service at an intermediate level between an application program and the Internet Protocol (IP). Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets may be lost, duplicated, or delivered out-of-order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the receiving application. Thus, TCP abstracts the application's communication from the underlying networking details. The TCP is utilized extensively by many of the Internet's most popular applications, including the World Wide Web (WWW), E-mail, File Transfer Protocol, Secure Shell, peer-to-peer file sharing, and some streaming media applications.
While IP layer handles actual delivery of the data, TCP keeps track of the individual units of data transmission, called segments, which are divided smaller pieces of a message, or data for efficient routing through the network. For example, when an HTML file is sent from a web server, the TCP software layer of that server divides the sequence of octets of the file into segments and forwards them individually to the IP software layer (Internet Layer). The Internet Layer encapsulates each TCP segment into an IP packet by adding a header that includes (among other data) the destination IP address. When the client program on the destination computer receives them, the TCP layer (Transport Layer) reassembles the individual segments and ensures they are correctly ordered and error-free as it streams them to an application.
The TCP protocol operations may be divided into three phases. First, the connections must be properly established in a multi-step handshake process (connection establishment) before entering the data transfer phase. After data transmission is completed, the connection termination closes established virtual circuits and releases all allocated resources. A TCP connection is typically managed by an operating system through a programming interface that represents the local end-point for communications, the Internet socket. The local end-point undergoes a series of state changes throughout the duration of a TCP connection.
The Internet Protocol (IP) is the principal communications protocol used for relaying datagrams (packets) across a network using the Internet Protocol Suite. It is considered as the primary protocol that establishes the Internet, and is responsible for routing packets across the network boundaries. IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering datagrams from the source host to the destination host based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation. Internet Protocol Version 4 (IPv4) is the dominant protocol of the Internet. IPv4 is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 791 and RFC 1349, and the successor, Internet Protocol Version 6 (IPv6), is currently active and in growing deployment worldwide. IPv4 uses 32-bit addresses (providing 4 billion: 4.3×109 addresses), while IPv6 uses 128-bit addresses (providing 340 undecillion or 3.4×1038 addresses), as described in RFC 2460.
An overview of an IP-based packet 25 is shown in FIG. 2a. The packet 25 may be generally segmented into an IP data 26b to be carried as a payload, and an IP header 26f. The IP header 26f contains an IP address of the source as a Source IP Address field 26d and a Destination IP Address field 26c. In most cases, the IP header 26f and the payload 26b are further encapsulated by adding a Frame Header 26e and a Frame Footer 26a used by higher layer protocols.
The Internet Protocol is responsible for addressing hosts and routing datagrams (packets) from a source host to the destination host across one or more IP networks. For this purpose, the Internet Protocol defines an addressing system that has two functions: Identifying hosts addresses and providing a logical location service. Each packet is tagged with a header that contains the meta-data for the purpose of delivery. This process of tagging is also called encapsulation. IP is a connectionless protocol for use in a packet-switched Link Layer network, and does not need circuit setup prior to transmission. The aspects of guaranteeing delivery, proper sequencing, avoidance of duplicate delivery, and data integrity are addressed by an upper transport layer protocol (e.g., TCP-Transmission Control Protocol and UDP-User Datagram Protocol).
The main aspects of the IP technology are IP addressing and routing. Addressing refers to how IP addresses are assigned to end hosts and how sub-networks of IP host addresses are divided and grouped together. IP routing is performed by all hosts, but most importantly by internetwork routers, which typically use either Interior Gateway Protocols (IGPs) or External Gateway Protocols (EGPs) to help make IP datagram forwarding decisions across IP connected networks. Core routers that are serving in the Internet backbone commonly use the Border Gateway Protocol (BGP) as per RFC 4098 or Multi-Protocol Label Switching (MPLS). Other prior art publications relating to Internet related protocols and routing include the following chapters of the publication number 1-587005-001-3 by Cisco Systems, Inc. (7/99) entitled: “Internetworking Technologies Handbook”, which are all incorporated in their entirety for all purposes as if fully set forth herein: Chapter 5: “Routing Basics” (pages 5-1 to 5-10), Chapter 30: “Internet Protocols” (pages 30-1 to 30-16), Chapter 32: “IPv6” (pages 32-1 to 32-6), Chapter 45: “OSI Routing” (pages 45-1 to 45-8) and Chapter 51: “Security” (pages 51-1 to 51-12), as well as in a IBM Corporation, International Technical Support Organization Redbook Documents No. GG24-4756-00 entitled: “Local Area Network Concepts and Products: LAN Operation Systems and Management”, 1st Edition May 1996, Redbook Document No. GG24-4338-00, entitled: “Introduction to Networking Technologies”, 1st Edition April 1994, Redbook Document No. GG24-2580-01 “IP Network Design Guide”, 2nd Edition June 1999, and Redbook Document No. GG24-3376-07 “TCP/IP Tutorial and Technical Overview”, ISBN 0738494682 8th Edition December 2006, which are incorporated in their entirety for all purposes as if fully set forth herein. Programming, designing, and using the Internet is described in a book by Paul S. Wang and Sanda Katila entitled: “An Introduction to Web Design+Programming” (Brooks/Cole book/Dec. 24, 2003), which is incorporated in its entirety for all purposes as if fully set forth herein.
The Internet architecture employs a client-server model, among other arrangements. The terms ‘server’ or ‘server computer’ relates herein to a device or computer (or a plurality of computers) connected to the Internet and is used for providing facilities or services to other computers or other devices (referred to in this context as ‘clients’) connected to the Internet. A server is commonly a host with an IP address that executes a ‘server program’, and typically operates as a socket listener. Many servers have dedicated functionalities such as web server, Domain Name System (DNS) server (described in RFC 1034 and RFC 1035), Dynamic Host Configuration Protocol (DHCP) server (described in RFC 2131 and RFC 3315), mail server, File Transfer Protocol (FTP) server and database server. Similarly, the term ‘client’ is used herein to include, but not limited to, a program or to a device or a computer (or a series of computers) executing this program, which accesses a server over the Internet for a service or a resource. Clients commonly initiate connections that a server may accept. For non-limiting example, web browsers are clients that connect to web servers for retrieving web pages and email clients connect to mail storage servers for retrieving mails.
The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems, commonly used for communication over the Internet. HTTP is the protocol to exchange or transfer hypertext, which is a structured text that uses logical links (hyperlinks) between nodes containing text. HTTP version 1.1 was standardized as RFC 2616 (June 1999), which was replaced by a set of standards (obsoleting RFC 2616), including RFC 7230-HTTP/1.1: Message Syntax and Routing, RFC 7231-HTTP/1.1: Semantics and Content, RFC 7232-HTTP/1.1: Conditional Requests, RFC 7233-HTTP/1.1: Range Requests, RFC 7234-HTTP/1.1: Caching, and RFC 7235-HTTP/1.1: Authentication. HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may further contain a requested content in its message body. A web browser is an example of a User Agent (UA). Other types of user agent include the indexing software used by search providers (web crawlers), voice browsers, mobile apps and other software that accesses, consumes, or displays web content.
HTTP is a protocol designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from web cache servers that deliver content on behalf of upstream servers to improve response time. In order to reduce network traffic, web browsers cache previously accessed web resources and reuse them when possible. HTTP proxy servers at private network boundaries may facilitate communication for clients without a globally routable address, by relaying messages with external servers. HTTP is an application layer protocol designed within the framework of the Internet Protocol Suite. Typically, HTTP uses an underlying and a reliable transport layer protocol, referred to as Transmission Control Protocol (TCP). However, it may also use unreliable protocols such as the User Datagram Protocol (UDP), for example, in the Simple Service Discovery Protocol (SSDP). HTTP resources are identified and located on the network by Uniform Resource Identifiers (URIs) or, more specifically, Uniform Resource Locators (URLs), using the http or https URI schemes. URIs and hyperlinks in Hypertext Markup Language (HTML) documents form webs of interlinked hypertext documents. An HTTP session is a sequence of network request-response transactions. The HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server. An HTTP server listening on that port waits for a client's request message. Upon receiving the request, the server sends back a status line, such as “HTTP/1.1 200 OK”, and a message of its own. The body of this message is typically the requested resource, although an error message or other information may also be returned. HTTP is a stateless protocol. A stateless protocol does not require the HTTP server to retain information or status.
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, refers to using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field. The HTTP persistent connection is described in IETF RFC 2616, entitled: “Hypertext Transfer Protocol—HTTP/1.1”. In HTTP 1.1, all connections are considered persistent unless declared otherwise. The HTTP persistent connections do not use separate ‘keepalive’ messages, but they allow multiple requests to use a single connection. The advantages of using persistent connections involve lower CPU and memory usage (because fewer connections are open simultaneously), enabling HTTP pipelining of requests and responses, reduced network congestion (due to fewer TCP connections), and reduced latency in subsequent requests (due to minimal handshaking). Any connection herein may use, or be based on an HTTP persistent connection.
The HTTP protocol allows for byte serving (a.k.a. ‘Byte Range Serving’ and ‘range request’), pertaining to the process of sending only a portion of an HTTP/1.1 message or a content from a server to a client, as described in section 14.35.2 of IETF RFC 2616 stating that the client may make ‘Range Retrieval Requests’ for partial content request. Byte serving begins when an HTTP server advertises its willingness to serve partial requests using the Accept-Ranges response header. A client then requests a specific part of a file from the server using the Range request header, and if the range is valid, the server sends it to the client with a 206 Partial Content status code and a Content-Range header listing the range sent. If the range is invalid, the server responds with a 416 ‘Requested Range Not Satisfiable’ status code. Alternatively or in addition, byte or range serving may be according to, compatible with, or based on IETF RFC 7233 entitled: “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, defining range requests and the rules for constructing and combining responses to those requests, which is incorporated in its entirety for all purposes as if fully set forth herein.
Byte Serving may be used for bandwidth optimization, where Clients request byte-serving in cases in which a large file has been only partially delivered, or where a limited portion of the file is needed in a particular range. By allowing byte serving, clients may choose to request any portion of the resource, so when a large media file is being requested, that media file may be properly formatted, so that the client may request just the portions of the file known to be of interest. Using range request in a Video-on-Demand scheme is described in an article by Dominik Kaspar, Kristian Evensen, Paal Engelstad, Audun F. Hansen, Pal Halvorsen, and Carsten Griwodz of Norway, entitled: “Enhancing Video-on-Demand Playout over Multiple Heterogeneous Access Networks”, which is incorporated in its entirety for all purposes as if fully set forth herein.
User. The term “user” is used herein to include, but not limited to, the principal using a client to interactively retrieve and render resources or resource manifestation, such as a person using a web browser, a person using an e-mail reader, or a person using a display such as the display 17.
Object. The term ‘object’ is used herein to include, but not limited to, a collection of data and operations, such as text, images, sound files, video data, documents, or any other of information that is presentable to a user of a computer system, and further include the case wherein the data and operations are arranged as object code or an object file. An object code (a.k.a, object module) is a compiled sequence of statements or instructions in a computer language, usually a machine code language or an intermediate language such as RTL. Object code is typically a portion of machine code that yet to be linked into a complete program in order to make up the completed product. It may also contain placeholders or offsets not found in the machine code of a completed program that the linker uses to connect everything together. An assembler is commonly used to convert assembly code into machine code (object code). A linker may link several object (and library) files to generate an executable program.
Object files can in turn be linked to form an executable file or library file. In order to be used, object code must be placed in an executable file, a library file, or an object file. An object file is a file containing object code that is usually not directly executable. Object files are produced by an assembler, compiler, or other language translator, and used as input to the linker, which in turn typically generates an executable or library by combining parts of object files. In addition to the object code itself, object files contain metadata used for linking or debugging information to resolve symbolic cross-references between different modules, relocation information, stack unwinding information, comments, program symbols, debugging, or profiling information.
Markup Language. A markup language is a set of tags and/or a set of rules for creating tags that can be embedded in digital text to provide additional information about the text in order to facilitate automated processing of it, including editing and formatting for display or printing. A markup language is typically used for annotating a document in a way that is syntactically distinguishable from the text. Instructions are expressed directly by tags or “instruction text encapsulated by tags”. Examples include typesetting instructions such as those found in troff, TeX and LaTeX, or structural markers such as XML tags. A Markup code instructs the software displaying the text to carry out appropriate actions, but the actions are usually omitted from the version of the text visible to the users. Some markup languages, such as the widely used HTML, have pre-defined presentation semantics. It means that their specification prescribes how to present the structured data. Others, such as XML, do not. HyperText Markup Language (HTML), one of the document formats of the World Wide Web, is an instance of SGML, and follows many of the markup conventions used in the publishing industry in the communication of printed work between authors, editors, and printers.
Descriptive markup is commonly used to label parts of the document rather than to provide specific instructions as to how they should be processed. The objective is to decouple the inherent structure of the document from any particular treatment or rendition of it, and such markup is often described as ‘semantic’. An example of descriptive markup would be HTML <cite> tag, which is used to label a citation. Descriptive markup, sometimes called logical markup or conceptual markup, enables authors to write in a way that describes the material conceptually, rather than visually.
A common feature of many markup languages is that they intermix the text of a document with markup instructions in the same data stream or file. This is not necessary; it is possible to isolate markup from text content, using pointers, offsets, IDs, or other methods to co-ordinate the two. Such “standoff markup” is typical for the internal representations that programs use to work with marked-up documents. Example of markup languages commonly used in Internet browsing include Hypertext Markup Language (HTML), Extensible Hypertext Markup Language (XHTML), Scalable Vector Graphics (SVG), Cascading Style Sheets (CSS), and Extensible Markup Language (XML).
HTML. HyperText Markup Language, commonly referred to as HTML, is the standard markup language used to create web pages. It is written in the form of HTML elements consisting of tags enclosed in angle brackets (like <html>). HTML tags most commonly come in pairs like <h1> and </h1>, although some represent empty elements, and so are unpaired, for example <img>. The first tag in such a pair is the start tag, and the second is the end tag (they are also called opening tags and closing tags). Web browsers can read HTML files and render them into visible or audible web pages; using HTML elements form the building blocks of all websites. Browsers do not display the HTML tags and scripts but use them to interpret the content of the page. HTML describes the structure of a website semantically along with cues for presentation, making it a markup language, rather than a programming language. HTML allows images and objects to be embedded and can be used to create interactive forms. It provides a means to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists, links, quotes and other items. It can embed scripts written in languages such as JavaScript, which affects the behavior of HTML web pages. HTML markup consists of several key components, including tags (and their attributes), character-based data types, character references and entity references. Another important component is the Document Type Declaration (DTD), which triggers standards mode rendering.
In the case of HTML type program file, the objects may be HTML elements. An HTML element is an individual component of an HTML document or web page, once parsed into the Document Object Model (DOM). HTML is composed of a tree of HTML elements and other nodes, such as text nodes. Each element can have HTML attributes specified. Elements can also have content, including other elements and text. HTML elements represent semantics or meaning, for example, the title element represents the title of the document. HTML documents are delivered as “documents” that are parsed and turned into the Document Object Model (DOM) internal representation, within the web browser. Presentation by the web browser, such as screen rendering or access by JavaScript, is then performed on this internal model, not the original document.
There are multiple kinds of HTML elements: void elements, raw text elements, and normal elements. Void elements only have a start tags and may contain any HTML attributes. They may not contain any children, such as text or other elements. Often they are placeholders for elements that reference external files, such as the image (<img/>) element. Raw text elements are constructed with: a start tag (<tag>) marking the beginning of an element, which may incorporate any number of HTML attributes, some amount of text content, but no elements (all tags, apart from the applicable end tag, will be interpreted as content), and an end tag in which the element name is prefixed with a slash: </tag>. In some versions of HTML, the end tag is optional for some elements. Normal elements usually have both a start tag and an end tag, but for some elements, the end tag, or both tags may be omitted. It is constructed in a similar way: a start tag (<tag>) marking the beginning of an element, which may incorporate any number of HTML attributes, content such as text and other elements, and an end tag, in which the element name is prefixed with a slash: </tag>. HTML attributes define desired behavior or indicate additional element properties. Most attributes require a value. In HTML, the value can be left unquoted if it does not include spaces (name=value), or it can be quoted with single or double quotes (name=‘value’ or name=“value”). HTML is described in a book published by John Wiley & Sons, Inc. 2011 (ISBN—978-1-118-00818-8) authored by Jon Duckett entitled: “HTML & CSS—Design and Build Websites”, HTML 2.0 is described in IETF RFC 1866 entitled: “Hypertext Markup Language—2.0”, HTML 4.01 (standardized as ISO/IEC 15445:200) is described in the World Wide Web Consortium (W3C) Proposed Recommendation (24 Aug. 1999) entitled: “HTML 4.01 Specification”, HTML 5 is described in the W3C Editor's Draft (9 Aug. 2010) entitled: “HTML5 Reference—The Syntax, Vocabulary, and APIs of HTML5”, and HTML 5.1 is described in W3C Editor's Draft (23 Mar. 2015) entitled: “HTML 5.1 Nightly”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
CSS. Cascading Style Sheets (CSS) is a style sheet language used for describing the look and formatting of a document written in a markup language. While most often used to change the style of web pages and user interfaces written in HTML and XHTML, the language can be applied to any kind of XML document, including plain XML, SVG and XUL. Along with HTML and JavaScript, CSS is a technology used by many websites to create visually engaging webpages, user interfaces for web applications, and user interfaces for many mobile applications. CSS makes it possible to separate presentation instructions from the HTML content in a separate file, or style section of the HTML file. For each matching HTML element, it provides a list of formatting instructions. For example, a CSS rule might specify that “all heading 1 elements should be bold,” leaving pure semantic HTML markup that asserts “this text is a level 1 heading” without formatting code such as a <bold> tag indicating how such text should be displayed.
CSS is designed primarily to enable the separation of document content from document presentation, including elements such as the layout, colors, and fonts. This separation of formatting and content makes it possible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (when read out by a speech-based browser or screen reader) and on Braille-based tactile devices. It can also be used to display the web page differently depending on the screen size or device on which it is being viewed. While the author of a web page typically links to a CSS file within the markup file, readers can specify a different style sheet, such as a CSS file stored on their own computer, to override the one the author has specified. If the author or the reader did not link the document to a style sheet, the default style of the browser will be applied. Another advantage of CSS is that aesthetic changes to the graphic design of a document (or hundreds of documents) can be applied quickly and easily by editing a few lines in one file, rather than by a laborious (and thus expensive) process of crawling over every document line-by-line, changing markup.
The CSS specification describes a priority scheme to determine which style rules apply if more than one rule matches against a particular element. In this so-called cascade, priorities or weights are calculated and assigned to rules, so that the results are predictable. The CSS specifications are maintained by the World Wide Web Consortium (W3C), and Internet media type (MIME type) text/css is registered for use with CSS by RFC 2318 (March 1998). CSS is further described in a book published by John Wiley & Sons, Inc. 2011 (ISBN-978-1-118-00818-8) authored by Jon Duckett entitled: “HTML & CSS-Design and Build Websites”, CSS 2.1 is described in W3C recommendation (7 Jun. 2011) entitled: “Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification”, IETF RFC 2318 entitled: “The text/css Media Type”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
SGML. The Standard Generalized Markup Language (SGML) is a standard for defining generalized markup languages for documents. Generalized markup is based on two postulates: Markup should be declarative, and it should describe a document's structure and other attributes, rather than specify the processing to be performed on it. Declarative markup is less likely to conflict with unforeseen future processing needs and techniques. Markup should be rigorous so that the techniques available for processing precisely defined objects, like programs and databases, may be used for processing documents as well. The SGML is standardized as International Standard ISO 8879-1986 entitled: “Information Processing—Text and Office Systems—Standard Generalized Markup Language (SGML)—First Edition” where ISO 8879 Annex A.1 defines generalized markup, and is further described in ISO/IEC TR 9573, entitled: “Information processing—SGML support facilities—Techniques for using SGML”. SGML is further described in a paper by Michel Goossens and Janne Saarela of CERN, CN Division of Geneva, Switzerland, entitled: “A practical introduction to SGML”, in a paper by Diego Calvanese, Giuseppe De Giancomo, and Maurizio Lenzerini of Universita di Roma, Italy, entitled: “Representing and Reasoning on SGML Documents”, in a paper by David Barron published 1989 by John Wiley & Sons, Ltd. (0894-3982/89/010003-22)—published Electronic Publishing, Vol. 2(1), 3-24 (April 1989), entitled: “Why use SGML?”, and in a paper by Jos Warmer and Sylvia Van Egmond published 1989 by John Wiley & Sons, Ltd. (0894-3982/89/020065-26)—published Electronic Publishing, Vol. 2(2), 65-90 (December 1989), entitled: “The implementation of the Amsterdam SGML Parser”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
XML. Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable. The design goals of XML emphasize simplicity, generality and usability across the Internet. It is a textual data format with strong support via Unicode for different human languages. While the design of XML focuses on documents, it is commonly used for the representation of arbitrary data structures such as those used in web services. XML is described in W3C Recommendation 10 Feb. 1998 (REC-xml-19980210) entitled: “Extensible Markup Language (XML) 1.0”, rules for the construction of Internet Media Types for use when sending XML are described in IETF RFC 7303 entitled: “XML Media Types”, and various aspects of designing and deploying an XML-based language are detailed in IETF RFC 3470 entitled: “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
XHTML. Extensible Hypertext Markup Language (XHTML) is a family of XML markup languages that mirror or extend versions of the widely used Hypertext Markup Language (HTML), the language in which Web pages are formulated. XHTML is an application of XML that is a more restrictive subset of SGML, where the documents are well formed and may, therefore, be parsed using standard XML parsers.
XMLHttpRequest (XHR) is an API available to web browser scripting languages such as JavaScript, and is used to send HTTP or HTTPS requests to a web server and load the server response data back into the script. Data from the response can be used to alter the current document in the browser window without loading a new web page, and despite the name of the API, this data can be in the form of not only XML, but also JSON, HTML, or plain text.
The Ajax web development technique used by many websites to implement responsive and dynamic web applications depends on XMLHttpRequest. For security reasons, XMLHttpRequest requests follow the browser same-origin policy, and will therefore only succeed if they are made to the host that served the original web page. The XMLHttpRequest is described in Chapter 3 named: “XMLHttpRequest Object” in a book by Thomas Powell published 2008 (ISBN: 978-0-07-149216) entitled: “Ajax: The Complete Reference”, and in W3C Working Draft (17 Jan. 2012) entitled: “XMLHttpRequest Level 2”, which are both incorporated in their entirety for all purposes as if fully set forth herein. Examples of using XMLHttpRequest are described in U.S. Pat. No. 8,473,593 to Graham et al. entitled: “Method for Dynamically Generating Information Objects Based on a Restful Subscription request”, in U.S. Patent Application No. 2009/0222554 to Schneider entitled: “Statistics for Online Advertising”, and in U.S. Patent Application No. 2014/0244830 to Smacinih entitled: “Web Application Monitoring”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
AJAX. Ajax (short for ‘Asynchronous JavaScript and XML’) is a group of interrelated Web development techniques used on the client-side to create asynchronous Web applications. With Ajax, web applications can send data to and retrieve from a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Data can be retrieved using the XMLHttpRequest object, but despite the name, the use of XML is not required (JSON is often used in the AJAJ variant), and the requests do not need to be asynchronous. Ajax is not a single technology, but a group of technologies, and HTML and CSS can be used in combination to markup and style information. The DOM is accessed with JavaScript to dynamically display and allow the user to interact with the information presented. JavaScript and the XMLHttpRequest object provide a method for exchanging data asynchronously between a browser and a server to avoid full page reloads. Asynchronous HTML and HTTP (AHAH) involves using XMLHttpRequest to retrieve (X)HTML fragments, which are then inserted directly into the web page.
AJAX is described in a tutorial from tutorialpoint (downloaded 2015 from www.tutorialspoint.com) entitled: “AJAX—asynchronous javascript and xml”, and in a book authored by Thomas A. Powell published 2008 by The McGraw-Hill Companies (0-07-159662-3) entitled: “Ajax: The Complete reference”, which are both incorporated in their entirety for all purposes as if fully set forth herein. Examples of using AJAX are described in U.S. Pat. No. 7,861,213 to Wang entitled: “Mechanism for Developing AJAX Applications Using Java Swing Framework and Method for Using the Same”, in U.S. Pat. No. 8,037,484 to Backhouse et al. entitled: “Building Compound Extensible Ajax Applications”, in U.S. Pat. No. 8,250,585 to Higgins et al. entitled: “Extensible Framework for Managing UI State in a Composite AJAX Application”, in U.S. Pat. No. 8,413,044 to Mao entitled: “Method and System of Retrieving AJAX Web Page Content”, and in U.S. Pat. No. 8,527,862 to Scoda et al. entitled: “Methods for Making AJAX Web Applications Bookmarkable and Crawlable and Devices Thereof”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
DOM. The Document Object Model (DOM) is an Application Programming Interface (API) for valid HTML and well-formed XML documents, and defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term “document” is used in the broad sens; increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents. The nodes of every document are organized in a tree structure, called the DOM tree, and the objects in the DOM tree may be addressed and manipulated by using methods on the objects. To render a document such as an HTML page, most web browsers use an internal model similar to the DOM. The nodes of every document are organized in a tree structure, called the DOM tree, with topmost node named ‘Document object’. When an HTML page is rendered in browsers, the browser downloads the HTML into local memory and automatically parses it to display the page on the screen. The DOM is also the way JavaScript transmits the state of the browser in HTML pages. The DOM is described in a W3C Recommendation (7 Apr. 2004) entitled: “Document Object Model (DOM) Level 3 Core Specification—Version 1.0”, and in a W3C Last Call Working Draft (28 Apr. 2015) entitled: “W3C DOM4”, which are both incorporated in their entirety for all purposes as if fully set forth herein.
Script. A script is a program or sequence of instructions that may be interpreted or carried out by another program rather than by the computer processor (as a compiled program is). Scripts are programs typically written for a special run-time environment that can interpret (rather than compile) and automate the execution of tasks. Environments that can be automated through scripting include software applications, web pages within a web browser, the shells of Operating Systems (OS), and embedded systems.
A scripting language or script language is a programming language that supports scripts, programs written for a special run-time environment that can interpret (rather than compile) and automate the execution of tasks that could alternatively be executed one-by-one by a human operator. Environments that can be automated through scripting include software applications, web pages within a web browser, the shells of operating systems (OS), and embedded systems. A scripting language can be viewed as a domain-specific language for a particular environment; in the case of scripting an application, this is also known as an extension language. Scripting languages are also sometimes referred to as very high-level programming languages, as they operate at a high level of abstraction, or as control languages, particularly for job control languages on mainframes. Some languages have been conceived expressly as script languages, such as Perl, REXX (on IBM mainframes), JavaScript, and Tcl/Tk. In the context of the World Wide Web, Perl, VBScript, and similar script languages are commonly written to handle forms input or other services for a Web site and are processed on the Web server. A JavaScript script in a Web page runs “client-side” on the Web browser. Using a script markup language is described for example in a U.S. Pat. No. 7,945,853 to Kothari et al. entitled: “Script Markup”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Client/Server-Side Scripting. Client-side scripting generally refers to the class of computer programs on the web that are executed on the client-side, by the user's web browser, instead of server-side (on the web server). This type of computer programming is an important part of the Dynamic HTML (DHTML) concept, enabling web pages to be scripted; that is, to have different and changing content depending on user input, environmental conditions (such as the time of day), or other variables. Client-side scripts are often embedded within an HTML or XHTML document (hence known as an “embedded script”), but they may also be contained in a separate file, to which the document (or documents) that use it make reference (hence known as an “external script”). Upon request, the necessary files are sent to the user's computer by the web server (or servers) on which they reside. The user web browser executes the script, and then displays the document, including any visible output from the script. Client-side scripts may also contain instructions for the browser to follow in response to certain user actions, (e.g., clicking a button). Often, these instructions may be followed without further communication with the server. In contrast, server-side scripts, written in languages such as PHP, ASP.NET, Java, ColdFusion, Perl, Ruby, Go, Python, and server-side JavaScript, are executed by the web server when the user requests a document, and produce output in a format understandable by web browsers (usually HTML), which is then sent to the user's computer. The user cannot see the script's source code (unless the author publishes the code separately), and may not even be aware that a script was executed. Client side scripting is described in W3C Working Draft 14 May 1997 (WD-script-970314) entitled: “Client-side scripting and HTML”, in Chapter 9 of the Brooks/Cole Book (Jan. 28, 2003) entitled: “Client-Side Scripting: Javascript”, by Paul S. Wang and Sanda Katila entitled: “An Introduction to Web Design+Programming” (Brooks/Cole book/Dec. 24, 2003), and in an article by Ray Rischpater published in the ‘Proceedings of the 2006 Scheme and Functional Programming Workshop’, University of Chicago Technical Report TR-2006-06 entitled: “Scheme for Client-Side Scripting in Mobile Web Browsing—or AJAX-Like Behavior Without Javascript”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Server-side scripting is a technique used in web development that involves employing scripts on a web server to produce a response customized for each user (client) request to the website. The alternative is for the web server itself to deliver a static web page. Scripts may be written in any server-side scripting languages that are available. Server-side scripting is distinguished from client-side scripting where embedded scripts, such as JavaScript, are run client-side in a web browser. However, both techniques are often used together. Server-side scripting is often used to provide a customized interface for the user. These scripts may assemble client characteristics for use in customizing the response based on those characteristics, the user's requirements, access rights, etc. Server-side scripting also enables the website owner to hide the source code that generates the interface, whereas with client-side scripting, the user has access to all the code received by the client. Server-side scripting is described in an article by John D. Haney and Craig A. VanLengen of Northern Arizona University entitled: “Server-Side Scripting In JavaScript/Jscript And VBScript”, which is incorporated in its entirety for all purposes as if fully set forth herein.
XML. Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable. The design goals of XML emphasize simplicity, generality and usability across the Internet. It is a textual data format with strong support via Unicode for different human languages. The design of XML focuses on documents, however it is commonly used for the representation of arbitrary data structures such as those used in web services. Rules for the construction of Internet Media Types for use when sending XML are described in IETF RFC 7303 entitled: “XML Media Types”, and various aspects of designing and deploying an XML-based language are detailed in IETF RFC 3470 entitled: “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols”. 
Flash. Adobe Flash (formerly called Macromedia Flash and Shockwave Flash), also known as Flash, is a multimedia and software platform used for creating vector graphics, animation, games, and Rich Internet Applications (RIAs) that can be viewed, played, and executed in Adobe Flash Player. Flash is frequently used to add streamed video or audio players, advertisement and interactive multimedia content to web pages. The usage of Flash, however on websites is declining.
Flash manipulates vector and raster graphics to provide animation of text, drawings, and still images, allows bidirectional streaming of audio and video, and it can capture user input via mouse, keyboard, microphone and camera. Flash applications and animations can be programmed using the object-oriented language referred to as ActionScript. Adobe Flash Player makes the Flash content accessible on various operating systems such as Windows, OS X and Linux, and is available for web browsers (as a plug-in) under a few of the major operating systems, some smartphones and tablets, and a few other electronic devices using Flash Lite. Flash is further described in Macromedia, Inc. tutorial First Edition (dated September 2005) entitled: “Flash Tutorials—8”, which is incorporated in its entirety for all purposes as if fully set forth herein.
JavaScript. JavaScript (also known as ECMAScript) is a dynamic programming language, classified as a prototype-based scripting language with dynamic typing and first-class functions that provides a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles. It is commonly used as part of web browsers, allowing client-side scripts to interact with the user, control the browser, communicate asynchronously, and alter the displayed content. It may also be used in server-side network programming with runtime environments such as Node.js, game development, and the creation of desktop and mobile applications. The JavaScript language is standardized in ISO/IEC 16262:2011, entitled: “Information technology—Programming languages, their environments and system software interfaces—ECMAScript language specification”. The ECMAScript language is supported by many applications, especially Web browsers, where it is implemented by JavaScript, or, in the case of Internet Explorer, JScript. Implementations sometimes include extensions to the language, or to the standard library and related application programming interfaces (API) such as the World Wide Web Consortium (W3C) specified Document Object Model (DOM). This means that applications written in one implementation may be incompatible with another, unless written to use only as a common subset of supported features and APIs.
The JavaScript is further described in ECMA International Standard ECMA—262, 5.1 Edition/June 2011 entitled: “ECMAScript Language Specification”, and in the document by Martin Baier and KnowWare (Feb. 9, 2008) entitled: “Javascript for beginners”, which are both incorporated in their entirety for all purposes as if fully set forth herein. An example of using JavaScript is described in a U.S. Pat. No. 8,639,743 to Colton et al. entitled: “System and Method for On-The-Fly Rewriting of Javascript”, which is incorporated in its entirety for all purposes as if fully set forth herein.
ActionScript. ActionScript is an Object-Oriented Programming (OOP) language, designed specifically for Website animation and derived from HyperTalk, the scripting language for HyperCard, and is a dialect of ECMAScript, offering a superset of the syntax and semantics of JavaScript. ActionScript is used primarily for the development of websites and software targeting the Adobe Flash Player platform, used on Web pages in the form of embedded SWF files. ActionScript code is free form and thus may be created with whichever amount or style of whitespace that the author desires, and its basic syntax is derived from ECMAScript. ActionScript 3.0 is described in Adobe document (Last updated May 2, 2011) entitled: “Learning ACTIONSCRIPT 3.0”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Java. Java is a general-purpose computer programming language that is concurrent, class-based, object-oriented, and specifically designed to have as few implementation dependencies as possible. It is intended to let application developers “write once, run anywhere” (WORA), meaning that compiled Java code can run on all platforms that support Java without the need for recompilation. Java applications are typically compiled to bytecode that can run on any Java Virtual Machine (JVM) regardless of computer architecture, and is commonly used for client-server web applications. The Java language is described in the Oracle America, Inc. Specification JSR-337 Java® SE 8 Release, Version 8, March 2015 entitled: “The Java® Language Specification—Java SE 8 Edition”, and in an on-line book by David J. Eck (Version 6.0, June 2011) entitled: “Introduction to Programming Using Java”, which are both incorporated in their entirety for all purposes as if fully set forth herein.
Objective-C. Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language, and usually have .m filename extensions for Objective-C source code program files. Objective-C is a thin layer on top of C, and derives its object syntax from Smalltalk. All of the syntax for non-object-oriented operations (including primitive variables, pre-processing, expressions, function declarations, and function calls) is identical to that of C, while the syntax for object-oriented features is an implementation of Smalltalk-style messaging. The Objective-C model of object-oriented programming is based on message passing to object instances, where the target of a message is resolved at runtime, with the receiving object itself interpreting the message. Objective-C implementations typically use a thin runtime system that is written in C, which adds little to the size of the application. The Objective-C language is described in an Addison-Wesley published June 2011 book by Stephen G. Kochan (ISBN-13: 978-0-321-71139-7) entitled: “Programming in Objective-C, Third Edition”, and in an Apple Inc. Developer guide (2014-09-17) entitled: “Programming with Objective-C”, which are both incorporated in their entirety for all purposes as if fully set forth herein.
Resource. The term ‘resource’ or ‘web resource’ is used herein to include, but not limited to, any addressable unit of information or service or any content, in whole or in part, and may be an object code or object file, such as XML element or object or an HTML element or object. A resource may be abstract or physical, and is typically identified by a URI and has the property that all of its essential characteristics can be conveyed in a message that can be transferred across a network, and may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways. Examples of resources include an electronic document, an image, a service, a web page, a collection of web pages, a service that provides information from a database, e-mail message, and a Java class. One or more (explicit or implicit) relationships between two or more resources are referred to as a ‘link’. An area within a resource that can be the source or destination of zero, one, or more links is referred to as an ‘anchor’. An anchor may refer to the whole resource, particular parts of the resource, or to particular manifestations of the resource.
Resource manifestation. A resource manifestation refers to a rendition of a resource, typically at a specific point in time and space. The manifestation is commonly tailored to the resource properties, and may vary according to the accessing time or to the environment in which it is displayed.
Operating systems. An Operating System (OS) is software that manages computer hardware resources and provides common services for computer programs. The operating system is an essential component of any system software in a computer system, and most application programs usually require an operating system to function. For hardware functions such as input and output and memory allocation, the operating system acts as an intermediary between programs and the computer hardware, although the application code is usually executed directly by the hardware and will frequently make a system call to an OS function or be interrupted by it. Common features typically supported by operating systems include process management, interrupts handling, memory management, file system, device drivers, networking (such as TCP/IP and UDP), and Input/Output (I/O) handling. Examples of popular modern operating systems include Android, BSD, iOS, Linux, OS X, QNX, Microsoft Windows, Windows Phone, and IBM z/OS.
Process management: The operating system provides an interface between an application program and the computer hardware, so that an application program can interact with the hardware only by obeying rules and procedures programmed into the operating system. The operating system is also a set of services that simplify development and execution of application programs. Executing an application program involves the creation of a process by the operating system kernel that assigns memory space and other resources, establishes a priority for the process in multi-tasking systems, loads program binary code into memory, and initiates execution of the application program that then interacts with the user and with hardware devices. The OS must allocate resources to processes, enable processes to share and exchange information, protect the resources of each process from other processes, and enable synchronization among processes. The OS maintains a data structure for each process, which describes the state and resource ownership of that process, enabling the OS to exert control over each process.
In many modern operating systems, there can be more than one instance of a program loaded in memory at the same time. For example, more than one user could be executing the same program with each user having separate copies of the program loaded into memory. With some programs, known as re-entrant type, it is possible to have one copy loaded into memory, while several users have shared access to it so that they each can execute the same program-code. The processor (such as the processor 12) at any instant can only be executing one instruction from one program but several processes can be sustained over a period of time by assigning each process to the processor at intervals, while the remainder becomes temporarily inactive. A number of processes being executed over a period instead of at the same time, is referred to as concurrent execution. A multiprogramming or multitasking OS is a system executing many processes concurrently. A multiprogramming requires that the processor to be allocated to each process for a period, and de-allocated at an appropriate moment. If the processor is de-allocated during the execution of a process, it must be done in such a way that it can be restarted later as easily as possible.
There are two typical ways for an OS to regain control of the processor during a program's execution in order for the OS to perform de-allocation or allocation. First, the process issues a system call (sometimes called a software interrupt); for example, an I/O request occurs requesting to access a file on hard disk. Alternatively, a hardware interrupt occurs; for example, a key was pressed on the keyboard, or a timer runs out (used in pre-emptive multitasking). The stopping of one process and starting (or restarting) another process is called a context switch, or context change. In many modern operating systems, processes can consist of many sub-processes. This introduces the concept of a thread. A thread may be viewed as a sub-process; that is, a separate, independent sequence of execution within the code of one process. Threads are becoming increasingly important in the design of distributed and client-server systems and in software running on multi-processor systems.
Modes: Many contemporary processors incorporate a mode bit to define the execution capability of a program in the processor. This bit can be set to a kernel mode, or a user mode. A kernel mode is also commonly referred to as supervisor mode, monitor mode, or ring 0. In kernel mode, the processor can execute every instruction in its hardware repertoire, whereas in user mode, it can only execute a subset of the instructions. Instructions that can be executed only in kernel mode are called kernel, privileged, or protected instructions to distinguish them from the user mode instructions. For example, I/O instructions are privileged. Therefore, if an application program executes in user mode, it cannot perform its own I/O, and must request the OS to perform I/O on its behalf. The system may logically extend the mode bit to define areas of memory to be used when the processor is in kernel mode versus user mode. If the mode bit is set to kernel mode, the process executing in the processor can access either the kernel or the user partition of the memory. However, if user mode is set, the process can reference only the user memory space, hence two classes of memory are defined: the user space and the system space (or kernel, supervisor or protected space). In general, the mode bit extends the operating system protection rights, and is set by the user-mode trap instruction, also known as a supervisor call instruction. This instruction sets the mode bit, and branches to a fixed location in the system space. Since only the system code is loaded in the system space, only the system code can be invoked via a trap. When the OS has completed the supervisor call, it resets the mode bit to user mode prior to the return.
Computer operating systems provide different levels of access to resources, and these hierarchical protection domains are often referred to as ‘protection rings’, and are used to protect data and functionality from faults (by improving fault tolerance) and malicious behavior (by providing computer security). A protection ring is one of two or more hierarchical levels or layers of privilege within the architecture of a computer system. These levels may be hardware-enforced by some CPU architectures that provide different CPU modes at the hardware or microcode level. Rings are arranged in a hierarchy from most privileged (most trusted, usually numbered zero) to least privileged (least trusted, usually with the highest ring number). On most operating systems, kernel mode or ‘Ring 0’ is the level with the most privileges, and interacts most directly with the physical hardware such as the CPU and memory. Special gates between rings are provided to allow an outer ring to access an inner ring's resources in a predefined manner, as opposed to allowing arbitrary usage. Correctly gating access between rings can improve security by preventing programs from one ring or privilege level from misusing resources intended for programs in another. For example, spyware running as a user program in Ring 3 should be prevented from turning on a web camera without informing the user, since hardware access should be a Ring 1 function reserved for device drivers. Programs such as web browsers running in higher numbered rings, must request access to the network, a resource restricted to a lower numbered ring.
Kernel. With the aid of the firmware and device drivers, the kernel provides the most basic level of control over all of the computer's hardware devices. It manages memory access for programs in the RAM, it determines which programs get access to which hardware resources, sets up or resets the CPU operating states for optimal operation at all times, and organizes the data for long-term non-volatile storage with file systems on media such as disks, tapes, and flash memory. The part of the system executing in kernel supervisor state is called the kernel, or nucleus, of the operating system. The kernel operates as trusted software, meaning that when it was designed and implemented, it was intended to implement protection mechanisms that could not be covertly changed through the actions of untrusted software executing in user space. Extensions to the OS execute in user mode, so the OS does not rely on the correctness of those parts of the system software for correct operation of the OS. Hence, a fundamental design decision for any function to be incorporated into the OS is whether or not it needs to be implemented in the kernel. If it is implemented in the kernel, it will execute in kernel (supervisor) space, and have access to other parts of the kernel. It will also be trusted software by the other parts of the kernel. If the function is implemented to execute in user mode, it will have no access to kernel data structures.
A program executing in user-mode may request the kernel services using two techniques, namely a ‘System call’ and a ‘Message passing’. Operating systems are typically associated with one or the other of these two facilities, but commonly not both. Assuming that a user process wishes to invoke a particular target system function in the system call approach, using the trap instruction, so the system call should appear to be an ordinary procedure call to the application program: the OS provides a library of user functions with names corresponding to each actual system call. Each of these stub functions contains a trap to the OS function, and when the application program calls the stub, it executes the trap instruction, which switches the CPU to kernel mode, and then branches (indirectly through an OS table) to the entry point of the function being invoked. When the function completes, it switches the processor to user mode and then returns control to the user process; thus simulating a normal procedure return. In the message passing approach, the user process constructs a message, that describes the desired service, and then it uses a trusted send function to pass the message to a trusted OS process. The send function serves the same purpose as the trap; that is, it carefully checks the message, switches the processor to kernel mode, and then delivers the message to a process that implements the target functions. Meanwhile, the user process waits for the result of the service request with a message receive operation. When the OS process completes the operation, it sends a message back to the user process.
Interrupts handling. Interrupts are central to operating systems, as they provide an efficient way for the operating system to interact with and react to its environment. Interrupts are typically handled by the operating system kernel for providing a way of automatically saving local register contexts and running specific code in response to events. When an interrupt is received, the computer's hardware automatically suspends whatever program is currently running, saves its status, and runs computer code previously associated with the interrupt. When a hardware device triggers an interrupt, the operating system's kernel decides how to deal with this event, generally by running some processing code. The amount of code being run depends on the priority of the interrupt, and the processing of hardware interrupts is executed by a device driver, which may be either part of the operating system kernel, part of another program, or both. Device drivers may then relay information to a running program by various means. A program may also trigger an interrupt to the operating system. For example, if a program wishes to access hardware (such as a peripheral), it may interrupt the operating system's kernel, which causes control to be passed back to the kernel. The kernel will then process the request. If a program wishes additional resources (or wishes to shed resources) such as memory, it will trigger an interrupt to get the kernel's attention. Each interrupt has its own interrupt handler. The number of hardware interrupts is limited by the number of interrupt request (IRQ) lines to the processor, but there may be hundreds of different software interrupts. Interrupts are a commonly-used technique for computer multitasking, especially in real-time computing systems, which are commonly referred to as interrupt-driven systems.
Memory management: A multiprogramming operating system kernel is responsible for managing all system memory that is currently in use by programs, ensuring that a program does not interfere with memory already in use by another program. Since programs share time, each program must have independent access to memory. Memory protection enables the kernel to limit the access of the process to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. In both segmentation and paging, certain protected mode registers specify to the CPU what memory address it should allow a running program to access. Attempts to access other addresses will trigger an interrupt that will cause the CPU to re-enter supervisor mode, placing the kernel in charge. This is called a segmentation violation (or Seg-V), and the kernel will generally resort to terminating the offending program, and will report the error.
Memory management further provides ways to dynamically allocate portions of memory to programs at their request, and frees it for reuse when no longer needed. This is critical for any advanced computer system, where more than a single process might be underway at any time. Virtual memory systems separate the memory addresses used by a process from actual physical addresses, allowing separation of processes and increasing the effectively available amount of RAM using paging or swapping to secondary storage. The quality of the virtual memory manager can have an extensive effect on overall system performance.
File system. Commonly a file system (or filesystem) is used to control how data is stored and retrieved. By separating the data into individual pieces, and giving each piece a name, the information is easily separated and identified, where each piece of data is referred to as a “file”. The structure and logic rules used to manage the groups of information and their names is collectively referred to as a “file system”. There are many different kinds of file systems, each one with a different structure and logic, properties of speed, flexibility, security, size, and more. Some file systems have been designed to be used for specific applications. For example, the ISO 9660 file system is designed specifically for optical discs. File systems can be used on many different kinds of storage devices. Some file systems are used on local data storage devices; others provide file access via a network protocol (for example, NFS, SMB, or 9P clients). Some file systems are “virtual”, in that the “files” supplied are computed on request (e.g., procfs), or are merely a mapping into a different file system used as a backing store. The file system manages access to both the content of files and the metadata about those files. It is responsible for arranging storage space, and reliability, efficiency, and tuning with regard to the physical storage medium are important design considerations.
A disk file system takes advantage of the ability of a disk storage media to randomly address data in a short amount of time. Additional considerations include the speed of accessing data, following that initially requested, and the anticipation that the following data may also be requested. This permits multiple users (or processes) access to various data on the disk without regard to the sequential location of the data. Examples include FAT (FAT12, FAT16, FAT32), exFAT, NTFS, HFS and HFS+, HPFS, UFS, ext2, ext3, ext4, XFS, btrfs, ISO 9660, Files-11, Veritas File System, VMFS, ZFS, ReiserFS, and UDF. Some disk file systems are journaling file systems or versioning file systems.
TMPFS. TMPFS (or tmpfs) is a common name for a temporary file storage facility on many Unix-like operating systems. While intended to appear as a mounted file system, it is stored in volatile memory instead of a non-volatile storage device. A similar construction is a RAM disk, which appears as a virtual disk drive, and hosts a disk file system. The tmpfs is typically a file system based on SunOS virtual memory resources, which does not use traditional non-volatile media to store file data; instead, tmpfs files exist solely in virtual memory maintained by the UNIX kernel. Because tmpfs file systems do not use dedicated physical memory for file data, but instead use VM system resources and facilities, they can take advantage of kernel resource management policies. Tmpfs is designed primarily as a performance enhancement to allow short-lived files to be written and accessed without generating disk or network I/O. Tmpfs maximizes file manipulation speed while preserving UNIX file semantics. It does not require dedicated disk space for files, and has no negative performance impact. The tmpfs is described in a Sun Microsystem Inc. paper entitled: “tmpfs: A Virtual Memory File System” by Peter Snyder, downloaded on July 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
Device drivers. A device driver is a specific type of computer software developed to allow interaction with hardware devices. Typically, this constitutes an interface for communicating with the device, through the specific computer bus or communications subsystem that the hardware is connected to, providing commands to and/or receiving data from the device, and on the other end, the requisite interfaces to the operating system and software applications. It is a specialized hardware-dependent computer program (that is also operating system specific) that enables another program such as an operating system, an applications software package, or a computer program running under the operating system kernel, to interact transparently with a hardware device, and usually provides the requisite interrupt handling necessary for any necessary asynchronous time-dependent hardware interfacing needs.
Networking: Most operating systems support a variety of networking protocols, hardware, and applications for using them, allowing computers running dissimilar operating systems to participate in a common network for sharing resources such as computing, files, printers, and scanners, using either wired or wireless connections. Networking can essentially allow a computer's operating system to access the resources of a remote computer, to support the same functions as it could if those resources were connected directly to the local computer. This includes everything from simple communication to using networked file systems, or sharing another computer's graphics or sound hardware. Some network services allow the resources of a computer to be accessed transparently, such as SSH, which allows networked users direct access to a computer's command line interface. A client/server networking allows a program on a computer, called a client, to connect via a network to another computer, called a server.
The term ‘client’ typically refers to an application (or a device executing the application) used for retrieving or rendering resources, or resource manifestations, such as a web browser, an e-mail reader, or a Usenet reader, while the term ‘server’ typically refers to an application (or a device executing the application) used for supplying resources or resource manifestations, and typically offers (or hosts) various services to other network computers and users. These services are usually provided through ports or numbered access points beyond the server's network address. Each port number is usually associated with a maximum of one running program, which is responsible for handling requests to that port. A daemon, being a user program, can in turn access the local hardware resources of that computer by passing requests to the operating system kernel.
Input/Output (I/O) handling: An input/output (or I/O) is the communication between an information processing system (such as a computer) and the outside world, possibly a human or other information processing system. The inputs are typically the signals or data received by the system, and the outputs are the signals or data sent from it. I/O devices may be used by a person (or another system) to communicate with a computer. For instance, a keyboard or a mouse may be an input device for a computer, while monitors and printers are considered output devices for a computer. Devices for communication between computers, such as modems and network cards, typically serve for both input and output.
User interface. Every computer that is to be operated by a human being (user) requires a user interface, usually referred to as a ‘shell’, and is essential if human interaction is to be supported. The user interface views the directory structure and requests services from the operating system that will acquire data from input hardware devices, such as a keyboard, mouse, or credit card reader, and requests operating system services to display prompts and status messages and such on output hardware devices, such as a video monitor or printer. The two most common forms of a user interface have historically been the command-line interface, where computer commands are typed out line-by-line, and the Graphical User Interface (GUI), where a visual environment (most commonly a WIMP) is present. Typically, the GUI is integrated into the kernel, allowing the GUI to be more responsive by reducing the number of context switches required for the GUI to perform its output functions.
WDM. The Windows Driver Model (WDM), also known as the Win32 Driver Model, is a standard model defining a framework for device drivers specified by Microsoft, providing unified driver models. The WDM model is based on using WDM drivers that are layered in a complex hierarchy and communicate with each other via I/O Request Packets (IRPs). The WDM is described in the publication entitled: “Microsoft Windows Driver Model (WDM)”, by Mohamad (Hani) Atassy, submitted to Dr. Dennis R. Hafermann dated Jan. 28, 2002, and in publication entitled: “A Comparison of the Linux and Windows Device Driver Architecture”, by Melekam Tsegaye and Ricahrd Foss, both from Rhodes University, South-Africa, downloaded from the Internet on July 2014, both are incorporated in their entirety for all purposes as if fully set forth herein.
A general schematic view of the WDM architecture 30 is shown on FIG. 3. In the example shown, three applications designated as an application #1 31a, an application #2 31b, and a web browser application #3 31c, are accessing three peripheral hardware devices, designated as peripheral #1 39a, peripheral #2 39b, and peripheral #3 39c. The model involves three layers. The lower layer is the hardware layer 34c, which includes the hardware devices and peripherals, accessed by the processor (such as the processor 12) via a hardware bus 34d, which may correspond to internal bus 13, shown in FIG. 1. The top layer is a ‘user space’ layer 34a, corresponding to the user mode and to the higher ‘ring’ layers, such as Ring 3, and is relating to the space is the memory area where application software and some drivers execute. The kernel of the operating system provides the services as part of a ‘kernel space’ layer 34b, serving as an intermediate layer between the user space layer 34a and the hardware layer 34c. The kernel space 34b operates in a highly privileged hierarchical protection domain, and is strictly reserved for running privileged kernel, kernel extensions, and most device drivers, and is typically corresponding to the kernel mode and to the ‘ring-0’ layer (in x86 processors). The kernel mode may be supported by the processor hardware, or may be supported by a code segment level.
The user mode applications (such as the application #1 31a, the application #2 31b, and the (web browser) application #3 31c exampled as a web browser application) access the kernel space 34b by the invoking the system calls respectively denoted as connections 32a, 32b, and 32c. Typically, such system calls are processed via intermediating entity known as Windows API, such as a Win32 API 33, which accesses the kernel space 34b via a standard messaging. The Win32 API 33 is an example of a Windows API (informally WinAPI), which is Microsoft's core set of Application Programming Interfaces (APIs) available in the Microsoft Windows operating systems. Almost all Windows programs interact with the Windows API. On the Windows NT line of operating systems, a small number (such as programs started early in the Windows startup process) uses the Native API. Supporting for developers is in the form of the Windows Software Development Kit (SDK), providing documentation and tools necessary to build software based upon the Windows API, and associated Windows interfaces. The Win32 API 33 is the 32-bit API for modern versions of Windows, and consists of functions implemented, as with Win16, in system DLLs. The core DLLs of the Win32 include the kernel32.dll, user32.dll, and gdi32.dll. The Win32 API is described in the tutorial entitled: “Welcome to Version 2.0 of the Win32 API Tutorial” by Prof. M. Saeed, published by Brook Miles, downloaded from the Internet on July 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
System calls provide an essential interface between a process and the operating system. A system call is how a program requests a service from an operating system's kernel. This may include hardware related services (e.g., accessing the hard disk), creating and executing new processes, and communicating with integral kernel services (such as scheduling). A system call is typically processed in the kernel mode, which is accomplished by changing the processor execution mode to a more privileged one. The hardware sees the world in terms of the execution mode according to the processor status register, and processes are an abstraction provided by the operating system. A system call does not require a context switch to another process; it is processed in the context of whichever process invoked it. The system calls are often executed via traps or interrupts that automatically puts the CPU into some required privilege level, and then pass control to the kernel, which determines whether the calling program should be granted the requested service. If the service is granted, the kernel executes a specific set of instructions over which the calling program has no direct control. It then returns the privilege level to that of the calling program, and turns over control to the calling program. Implementing system calls requires a control transfer, which involves some sort of architecture-specific feature.
System calls can be roughly grouped into five major categories: process control, such as load, execute, create/terminate process, get/set process attributes, wait for time, wait event, and signal event; file management, such as request/release device, create/delete file, open/close file, read/write/reposition file, and get/set file attributes; device management, such as read/write/reposition device, get/set device attributes, and logically attach/detach devices; information maintenance, such as get/set time or date, get/set system data, and get/set process, file, or device attributes; and communication such as create, delete communication connection, transfer status information, and attach or detach remote devices.
The system calls are commonly handled by an I/O manager 35b, which allows devices to communicate with user-mode subsystems. It translates user-mode read and write commands into read or write IRPs, which it passes to device drivers. It accepts file system I/O requests, translates them into device specific calls, and can incorporates low-level device drivers that directly manipulate hardware to either read input, or write output. It also includes a cache manager to improve disk performance by caching read requests and write to the disk in the background. The I/O manager 35b may interface a power manager 35c, which deals with power events (power-off, stand-by, hibernate, etc.), and notifies affected drivers with special IRPs (Power IRPs).
A PnP manager 35a handles ‘Plug and Play’ and supports device detection and installation at boot time. It also has the responsibility to stop and start devices on demand such as, when a bus (such as USB or FireWire) gains a new device and needs to have a device driver loaded to support it. The PnP manager 35a may be partly implemented in user mode, in the Plug and Play Service, which handles the complex tasks of installing the appropriate drivers, notifying services and applications of the arrival of new devices, and displaying GUI to the user.
I/O Request Packets (IRPs) are kernel mode structures that are used to communicate with each other and with the operating system. They are data structures that describe I/O requests to a driver, and parameters such as buffer address, buffer size, and I/O function type are passed via a single pointer to this persistent data structure. The IRP with all of its parameters can be put on a queue if the I/O request cannot be performed immediately. I/O completion is reported back to the I/O manager by passing its address to a routine for the purpose, IoCompleteRequest. The IRP may be repurposed as a special kernel APC object if such is required to report completion of the I/O to the requesting thread. IRPs are typically created by the I/O Manager in response to I/O requests from user mode. However, IRPs are sometimes created by the plug-and-play manager, power manager, and other system components, and can further be created by drivers, and then passed to other drivers.
The WDM uses kernel-mode device drivers to enable it to interact with hardware devices, where each of the drivers has well-defined system routines and internal routines that it exports to the rest of the operating system. DriverEntry is the first routine called after a driver is loaded, and is responsible for initializing the driver. All devices are seen by the user mode code as a file object in the I/O manager. In the I/O manager itself, the devices are seen as device objects, which can be defined as either file, device, or driver objects. The drivers may be aggregated as a driver stack 36, including kernel-mode drivers in three levels: high-level drivers 36a, intermediate-level drivers 36b, and low-level drivers 36c. The high-level drivers 36a, such as file system drivers for FAT and NTFS, rely on the intermediate-level drivers 36b, which consist of function drivers or main driver for a device that are optionally sandwiched between lower and higher-level filter drivers. The high-level drivers 36a typically know how files are represented on disk, but not the details of how to actually fetch the data.
The intermediate level drivers 36b process the requests from the highest-level driver by breaking down a large request into a series of small chunks. The function driver typically contains the details on how the hardware of the peripheral works, relies on a bus driver, or a driver that services a bus controller, adapter, or a bridge with an optional bus filter driver that sits between itself and the function driver. For example, a PCI bus driver detects the PCI-slot plugged card or hardware, and determines the I/O-mapped or the memory-mapped connection with the host. The intermediate drivers 36b rely on the low-level drivers 36c to function, and the lowest level drivers 36c are either legacy device drivers that control a device directly, or a PnP hardware bus. These lower level drivers 36c directly control hardware and do not rely on any other drivers. The I/O manager 35b communicates with the high-level driver 36a using IRP 37a, the high-level driver 36a communicates with the intermediate level driver 36b using IRP 37b, the intermediate-level driver 36b communicates with the low-level driver 36c using IRP 37c, and the low-level driver 37c communicates with the HAL 38 using IRP 37d. 
WDM drivers can be classified into the following types and sub-types: device function drivers, bus drivers, and filter drivers. A function driver is a main driver for a device, and is typically written by the device vendor, and is required (unless the device is being used in raw mode). A function driver can service one or more devices. Miniport drivers are a type of function drivers for interfaces such as USB, audio, SCSI and network adapters. They are hardware specific, but the control access to the hardware is through a specific bus class driver. Class drivers are a type of function drivers and can be thought of as built-in framework drivers for supporting miniport and other class drivers. The class drivers provide interfaces between different levels of the WDM architecture.
Common functionalities between different classes of drivers can be written into the class driver and be used by other class and miniport drivers. The lower edge of the class driver will have its interface exposed to the miniport driver, while the upper edge of the top-level class drivers is operating system specific. Class drivers can be dynamically loaded and unloaded at-will. They can do class specific functions that are not hardware or bus-specific (with the exception of bus-type class drivers), and in fact, sometimes only do class specific functions such as an enumeration.
A bus driver services a bus controller, adapter, or bridge. Microsoft provides bus drivers for most common buses, such as Advanced configuration and Power Interface (ACPI), Peripheral Component Interconnect (PCI), PnPISA, SCSI, Universal Serial Bus (USB), and FireWire. A bus driver can service more than one bus if there is more than one bus of the same type on the machine. The ACPI bus driver interacts with the ACPI BIOS to enumerate the devices in the system and control their power use, the PCI bus driver (such as pci.sys) enumerates and configures devices connected via the PCI bus, the FireWire and the USB bus driver respectively enumerates and controls devices connected via the IEEE 1394 high-speed bus and the USB. The stream class driver provides a basic processing supporting high bandwidth, time critical, and audio/video data related hardware, and uses minidrivers for interfacing the actual hardware. Hard-disk, floppies, CDs, and DVDs are interfaces that use SCSI and CDROM/DVD class driver. The Human Input Device (HID) provides an abstract view of input devices, and the Still Image Architecture (SIA) class driver is used to obtain content from a scanner and a still camera, using minidrivers. For example, accessing a hard disk (such as the storage 15a or the HDD 15C) may involve a file system driver as high-level driver, a volume manager driver as intermediate-level driver, and a disk driver as low-level driver.
Filter drivers are optional drivers that add value to, or modify the behavior of a device and may be non-device drivers. A filter driver can also service one or more devices. Upper-level filter drivers sit above the primary driver for the device (the function driver), while lower-level filter drivers sit below the function driver and above the bus driver. A driver service is a type of kernel-level filter driver implemented as a Windows service that enables applications to work with devices.
The Hardware Abstraction Layer 38, or HAL, is a layer between the physical hardware layer 34c of the computer and the rest of the operating system. It was designed to hide differences in hardware, and therefore provides a consistent platform on which the kernel is run. The HAL 38 includes hardware-specific code that controls I/O interfaces, and interrupts controllers and multiple processors. Typically, the particular hardware abstraction does not involve abstracting the instruction set, which generally falls under the wider concept of portability. Abstracting the instruction set, when necessary (such as for handling the several revisions to the x86 instruction set, or emulating a missing math coprocessor), is performed by the kernel, or conducted via platform virtualization.
Linux is a Unix-like and mostly POSIX-compliant computer operating system assembled under the model of free and open source software development and distribution. The defining component of Linux is the Linux kernel, an operating system kernel first released on 5 Oct. 1991 by Linus Torvalds. Linux was originally developed as a free operating system for Intel x86-based personal computers, but has since been ported to more computer hardware platforms than any other operating system. Linux also runs on embedded systems such as mobile phones, tablet computers, network routers, facility automation controls, televisions, and video game consoles. Android, which is a widely used operating system for mobile devices, is built on top of the Linux kernel. Typically, Linux is packaged in a format known as a Linux distribution for desktop and server use.
Linux distributions include the Linux kernel, supporting utilities and libraries and usually a large amount of application software to fulfill the distribution's intended use. A Linux-based system is a modular Unix-like operating system. Such a system uses a monolithic kernel, the Linux kernel, which handles process control, networking, and peripheral and file system access. Device drivers are either integrated directly with the kernel or added as modules loaded while the system is running. Some components of an installed Linux system are a bootloader, for example GNU GRUB or LILO, which is executed by the computer when it is first turned on, and loads the Linux kernel into memory, an init program. Init is the first process launched by the Linux kernel, and is at the root of the process tree, and it starts processes such as system services and login prompts (whether graphical or in terminal mode), software libraries containing code that can be used by running processes, and user interface programs such as command shells or windowing environments. A version of Linux is described, for example, in IBM Corporation (headquartered in Armonk, N.Y.) publication No. SC34-2597-03 entitled: “Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6.3”, downloaded from the Internet on July 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
The general schematic Linux driver architecture 30a is shown in FIG. 3a, and the Linux kernel is further described in Wiley Publishing, Inc. publication entitled: “Professional Linux Kernel Architecture”, by Wofgang Mauerer published 2008, and Linux programming is described in the book entitled: “The Linux Kernel Module Programming Guide” ver. 2.6.4 by Peter Jay Salzman, Michael Burian, and Ori Pomerantz, dated May 18, 2007, and in the publication entitled: “A Comparison of the Linux and Windows Device Driver Architecture”, by Melekam Tsegaye and Richard Foss, both from Rhodes University, South-Africa, downloaded from the Internet on July 2014, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Similar to the WDM 30 shown in FIG. 3, the Linux kernel involves a ‘System Call Interface’ 33a, receiving system calls 32d, 32e, and 32f from the respective applications such as an application #1 31a, an application #2 31b, and an application #3 31c, and serves as the denomination for the entirety of all implemented and available system calls in a kernel. The Linux kernel is based on a layered modules stack 36a which may include three levels of modules, such as module #1 36d, module #2 36e, and module #3 36f, where the module #1 36d communicate over connection 37e with the system call interface 33a, the module #2 36e communicates with the module #1 36d over connection 37f, and the module #3 36f communicates over the connection 37g with the module #2 36e and over a connection 37h with the HAL 38.
Similar to the WDM 30 shown in FIG. 3, the Linux kernel, shown as the arrangement 30a in FIG. 3a, is using the concept of layered architecture of a modules stack 36a, which may comprise module #1 36d, module #2 36e, and module #3 36f, communicating using messaging mechanism, such as a connection 37e between the system call interface 33a and the module #1 36d, a connection 37f between the module #1 36d and the module #2 36e, a connection 37g between the module #2 36e and the module #3 36f, and a connection 37h between the module #3 36f and the HAL 38.
The modules in the modules stack 36a, typically referred to as Loadable Kernel Modules (or LKM), are object files that contain code to extend the running Linux kernel, or so-called base kernel. LKMs are typically used to add support for new hardware and/or filesystems, or for adding system calls. When the functionality provided by an LKM is no longer required, it can be unloaded in order to free memory and other resources. Loadable kernel modules in Linux are located in /lib/modules and have had the extension ‘.ko’ (“kernel object”) since version 2.6 (previous versions used the .o extension), and are loaded (and unloaded) by the modprobe command. The lsmod command lists the loaded kernel modules. In emergency cases, when the system fails to boot (due to broken modules for example), specific modules can be enabled or disabled by modifying the kernel boot parameters list (for example, if using GRUB, by pressing ‘e’ in the GRUB start menu, then editing the kernel parameter line). Linux allows disabling module loading via sysctl option /proc/sys/kernel/modules_disabled. An initramfs system may load specific modules needed for a machine at boot, and then disable module loading.
Chrome OS is a Linux kernel-based operating system designed by Google Inc., Mountain View, Calif., U.S.A., to work primarily with web applications. The user interface takes a minimalist approach and consists almost entirely of just the Google Chrome web browser. Since the operating system is aimed at users who spend most of their computer time on the Web, the only “native” applications on Chrome OS are a browser, media player and file manager, making it almost a pure web thin client OS.
The Chrome OS includes a three-tier architecture with firmware, browser, and window manager, and a system-level software and Userland services. The firmware contributes to fast boot time by not probing for hardware, such as floppy disk drives that are no longer common on computers, especially netbooks. The firmware also contributes to security by verifying each step in the boot process and incorporating system recovery. The system-level software includes the Linux kernel that has been patched to improve boot performance. The Userland software has been trimmed to essentials, with management by Upstart, which can launch services in parallel, re-spawn crashed jobs, and defer services in the interest of faster booting. The Chrome OS user guide is described in the Samsung Electronics Co., Ltd. presentation entitled: “Google™ Chrome OS USER GUIDE” published 2011, which is incorporated in its entirety for all purposes as if fully set forth herein.
A mobile operating system (also referred to as mobile OS), is an operating system that operates a smartphone, tablet, PDA, or another mobile device. Modern mobile operating systems combine the features of a personal computer operating system with other features, including a touchscreen, cellular, Bluetooth, Wi-Fi, GPS mobile navigation, camera, video camera, speech recognition, voice recorder, music player, near field communication and infrared blaster. Currently, the popular mobile OSs include Android, Symbian, Apple iOS, BlackBerry, MeeGo, Windows Phone, and Bada. Mobile devices with mobile communications capabilities (e.g. smartphones) typically contain two mobile operating systems: a main user-facing software platform is supplemented by a second low-level proprietary real-time operating system that operates the radio and other hardware.
Android is a Linux-based, open source mobile operating system (OS) based on the Linux kernel that is currently offered by Google. With a user interface based on direct manipulation, Android is designed primarily for touchscreen mobile devices such as smartphones and tablet computers with specialized user interfaces for televisions (Android TV), cars (Android Auto), and wrist watches (Android Wear). The OS uses touch inputs that loosely correspond to real-world actions, such as swiping, tapping, pinching, and reverse pinching to manipulate on-screen objects, and a virtual keyboard. Despite being primarily designed for touchscreen input, it also has been used in game consoles, digital cameras, and other electronics. The response to user input is designed to be immediate and provides a fluid touch interface, often using the vibration capabilities of the device to provide haptic feedback to the user. Internal hardware such as accelerometers, gyroscopes and proximity sensors are used by some applications to respond to additional user actions. For example, adjusting the screen from portrait to landscape depending on the device orientation, or allowing the user to steer a vehicle in a racing game by rotating the device, a process that simulates control of a steering wheel.
Android devices boot to the homescreen, the primary navigation and information point on the device, which is similar to the desktop found on PCs. The homescreens on Android are typically made up of app icons and widgets. App icons launch the associated app, whereas widgets display live, auto-updating content such as the weather forecast, the user's email inbox, or a news ticker directly on the homescreen. A homescreen may be made up of several pages that the user can swipe back and forth between pages. A heavily-customizable Android homescreen interface allows the user to adjust the look and feel of the device to their liking. Third-party apps available on Google Play and other app stores can extensively re-theme the homescreen, and even mimic the look of other operating systems, such as Windows Phone. The Android OS is described in a publication entitled: “Android Tutorial”, downloaded from tutorialspoint.com on July 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
iOS (previously iPhone OS) from Apple Inc. (headquartered in Cupertino, Calif., U.S.A.) is a mobile operating system distributed exclusively for Apple hardware. The user interface of the iOS is based on the concept of direct manipulation, using multi-touch gestures. Interface control elements consist of sliders, switches, and buttons. Interaction with the OS includes gestures such as swipe, tap, pinch, and reverse pinch, all of which have specific definitions within the context of the iOS operating system and its multi-touch interface. Internal accelerometers are used by some applications to respond to shaking the device (one common result is the undo command), or rotating it in three dimensions (one common result is switching from portrait to landscape mode). The iOS is described in a publication entitled: “IOS Tutorial”, downloaded from tutorialspoint.com on July 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
A server device (in server/client architecture) typically offers information resources, services, and applications to clients, using a server dedicated or oriented operating system. A server device may consist of, be based on, include, or be included in the work-station 7, the computer system 10, or the computer 11. Current popular server operating systems are based on Microsoft Windows (by Microsoft Corporation, headquartered in Redmond, Wash., U.S.A.), Unix, and Linux-based solutions, such as the ‘Windows Server 2012’ server operating system, which is a part of the Microsoft ‘Windows Server’ OS family, that was released by Microsoft in 2012. ‘Windows Server 2012’ provides enterprise-class datacenter and hybrid cloud solutions that are simple to deploy, cost-effective, application-specific, and user-centric, and is described in Microsoft publication entitled: “Inside-Out Windows Server 2012”, by William R. Stanek, published 2013 by Microsoft Press, which is incorporated in its entirety for all purposes as if fully set forth herein.
Unix operating system is widely used in servers. It is a multitasking, multiuser computer operating system that exists in many variants, and is characterized by a modular design that is sometimes called the “Unix philosophy”, meaning the OS provides a set of simple tools, which each performs a limited, well-defined function, with a unified filesystem as the primary means of communication, and a shell scripting and command language to combine the tools to perform complex workflows. Unix was designed to be portable, multi-tasking and multi-user in a time-sharing configuration, and Unix systems are characterized by various concepts: the use of plain text for storing data, a hierarchical file system, treating devices and certain types of Inter-Process Communication (IPC) as files, the use of a large number of software tools, and small programs that can be strung together through a command line interpreter using pipes, as opposed to using a single monolithic program that includes all of the same functionality. Unix operating system consists of many utilities along with the master control program, the kernel. The kernel provides services to start and stop programs, handles the file system and other common “low level” tasks that most programs share, and schedules access to avoid conflicts when programs try to access the same resource, or device simultaneously. To mediate such access, the kernel has special rights, reflected in the division between user-space and kernel-space. Unix is described in a publication entitled: “UNIX Tutorial” by tutorialspoint.com, downloaded on July 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
Mail server. Mail server (a.k.a. Email server, Electronic Mail server, Mail Exchanger-MX) refer to a server operating as an electronic post office for email exchanging across networks, commonly performing the server-side of an MTA function. A Message Transfer Agent (or Mail Transfer Agent-MTA), or mail relay is a software that transfers electronic mail messages from one computer to another using a client-server application architecture. An MTA typically implements both the client (sending) and server (receiving) portions of the Simple Mail Transfer Protocol (SMTP). The Internet mail architecture is described in IETF RFC 5598 entitled: “Internet Mail Architecture”, and the SMTP protocol is described in IETF RFC 5321 entitled: “Simple Mail Transfer Protocol” and in IETF RFC 7504 entitled: “SMTP 521 and 556 Reply Codes”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
The Domain Name System (DNS) typically associates a mail server to a domain with mail exchanger (MX) resource records, containing the domain name of a host providing MTA services. A message transfer agent receives mail from either another MTA, a Mail Submission Agent (MSA), or a Mail User Agent (MUA). The transmission details are specified by the Simple Mail Transfer Protocol (SMTP). When a recipient mailbox of a message is not hosted locally, the message is relayed, that is, forwarded to another MTA. Every time an MTA receives an email message, it adds a ‘Received’ trace header field to the top of the header of the message, thereby building a sequential record of MTAs handling the message. The process of choosing a target MTA for the next hop is also described in SMTP, but can usually be overridden by configuring the MTA software with specific routes. Internet mail schemes are described in IEEE Annals of the History of Computing paper published 2008 by the IEEE Computer Society [1058-6180/08], authored by Craig Partridge of BBN Technologies entitled: “The technical Development of Internet Email”, which is incorporated in its entirety for all purposes as if fully set forth herein.
A mail server infrastructure consists of several components that work together to send, relay, receive, store, and deliver email, and typically uses various Internet standard protocols for sending and retrieving email, such as the Internet standard protocol Simple Mail Transfer Protocol (SMTP) for sending email, the Internet standard protocols for retrieving email Post Office Protocol (POP), and Internet Message Access Protocol version 4 (IMAPv4). An example of a mail server software is ‘Microsoft Exchange Server 2013’ (available from Microsoft Corporation, headquartered in Redmond, Wash., U.S.A.), described in ‘Pocket Consultant’ book [ISBN: 978-0-7356-8168-2] published 2013 by Microsoft Press and entitled: “Microsoft Exchange Server 2013—Configuration & Clients”, which is incorporated in its entirety for all purposes as if fully set forth herein.
The POP is specified in IETF RFC 1939 entitled: “Post Office Protocol”, and updated specification with an extension mechanism is described in IETF RFC 2449 entitled: “POP3 Extension Mechanism”, and an authentication mechanism is described in IETF RFC 1734 entitled: “POP3 AUTHentication command”, which are all incorporated in their entirety for all purposes as if fully set forth herein. IMAP4 clients can create, rename, and/or delete mailboxes (usually presented to the user as folders) on the mail server, and copy messages between mailboxes, and this multiple mailbox support also allows servers to access shared and public folders. IMAP4 is described in IETF RFC 3501 entitled: “INTERNET MESSAGE ACCESS PROTOCOL—VERSION 4rev1”, and the IMAP4 Access Control List (ACL) Extension may be used to regulate access rights, and is described in IETF RFC 4314 entitled: “IMAP4 Access Control List (ACL) Extension”, which are both incorporated in their entirety for all purposes as if fully set forth herein.
Mail servers may be operated, or used by mailbox providers, and mail servers are described in U.S. Pat. No. 5,832,218 to Gibbs et al. entitled: “Client/server Electronic Mail System for Providing Off-Line Client Utilization and Seamless Server Resynchronization”, in U.S. Pat. No. 6,081,832 to Gilchrist et al. entitled: “Object Oriented Mail Server Framework Mechanism”, in U.S. Pat. No. 7,136,901 to Chung et al. entitled: “Electronic Mail Server”, and in U.S. Pat. No. 7,818,383 to Kodama entitled: “E-Mail Server”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Database server. A database server is a server or computer program that is executed on a server device that provides database services to clients using a client-server model. Database management systems frequently provide database server functionality, and some DBMSs (e.g., MySQL) rely exclusively on the client-server model for database access. Most of the Database servers work with the base of Query language. Each Database understands its query language, converts it to Server readable form, and executes it to retrieve the results. Some examples of proprietary database servers are Oracle, DB2, Informix, and Microsoft SQL Server. The database software DB2 Version 9.5 (for Linux, UNIX, and Windows) is available from International Business Machines (IBM) Corporation and is described in an IBM published 2008 guide [SC23-5849-01] entitled: “Data Servers, Databases, and Database Objects Guide, Updated March, 2008”, which is incorporated in its entirety for all purposes as if fully set forth herein. The database software Microsoft SQL Server 2014 is available from Microsoft Corporation and is described in a Technical Overview published by Microsoft Press [ISBN: 978-0-7356-8475-1], entitled: “Introducing Microsoft SQL Server 2014—Technical Overview”, which is incorporated in its entirety for all purposes as if fully set forth herein.
A client device (in server/client architecture) typically receives information resources, services, and applications from servers, and is using a client dedicated or oriented operating system. The client device may consist of, be based on, include, or be included in, the workstation 7, the computer system 10 or the computer 11. Current popular client operating systems are based on Microsoft Windows (by Microsoft Corporation, headquartered in Redmond, Wash., U.S.A.), which is a series of graphical interface operating systems developed, marketed, and sold by Microsoft. Microsoft Windows is described in Microsoft publications entitled: “Windows Internals—Part 1” and “Windows Internals—Part 2”, by Mark Russinovich, David A. Solomon, and Alex Ioescu, published by Microsoft Press in 2012, which are both incorporated in their entirety for all purposes as if fully set forth herein. Windows 8 is a personal computer operating system developed by Microsoft as part of Windows NT family of operating systems, that was released for general availability on October 2012, and is described in Microsoft Press 2012 publication entitled: “Introducing Windows 8—An Overview for IT Professionals” by Jerry Honeycutt, which is incorporated in its entirety for all purposes as if fully set forth herein.
Web browser. A web browser 31c (commonly referred to as a browser) is a software application for retrieving, presenting, and traversing information resources on the World Wide Web. An information resource is identified by a Uniform Resource Identifier (URI/URL) and may be part of a web page, an image, a video, or any other piece of content. Hyperlinks present in resources enable users easily to easily navigate their browsers to related resources. Although browsers are primarily intended to use the World Wide Web, they can also be used to access information provided by web servers in private networks or files in file systems. The primary purpose of a web browser is to bring information resources to the user (“retrieval” or “fetching”), allowing them to view the information (“display”, “rendering”), and then access other information (“navigation”, “following links”). Currently the major web browsers are: Firefox, Internet Explorer, Google Chrome, Opera, and Safari.
The process begins when the user inputs a Uniform Resource Locator (URL), for example ‘http://en.wikipedia.org/’, into the browser. The prefix of the URL, the Uniform Resource Identifier (URI), determines how the URL will be interpreted. The most commonly used type of URI starts with ‘http:’, and identifies a resource to be retrieved over the Hypertext Transfer Protocol (HTTP). Many browsers also support a variety of other prefixes, such as ‘https:’ for HTTP Secure (HTTPS), ‘ftp:’ for the File Transfer Protocol (FTP), and ‘file:’ for local files. Prefixes that the web browser cannot directly handle are often handed off to another application entirely. For example, ‘mailto:’ URIs are usually passed to the user's default e-mail application, and ‘news:’ URIs are passed to the user's default newsgroup reader. In the case of http, https, file, and others, once the resource has been retrieved, the web browser will display it. HTML and associated content (image files, formatting information such as CSS, etc.) is passed to the browser's layout engine to be transformed from markup to an interactive document, a process known as “rendering”. Aside from HTML, web browsers can generally display any kind of content that can be part of a web page. Most browsers can display images, audio, video, and XML files, and often have plug-ins to support Flash applications and Java applets. Upon encountering a file of an unsupported type, or a file that is set up to be downloaded rather than displayed, the browser prompts the user to save the file to disk. Information resources may contain hyperlinks to other information resources. Each link contains the URI of a resource to go to. When a link is clicked, the browser navigates to the resource indicated by the link's target URI, and the process of bringing content to the user begins again.
Examples of web browsers functionalities and structures are described in U.S. Pat. No. 5,572,643 to Judson entitled: “Web Browser with Dynamic Display of Information Objects During Linking”, in U.S. Pat. No. 5,701,451 to Rogers et al. entitled: “A Method for Fulfilling Requests of a Web Server”, in U.S. Pat. No. 5,793,964 to Rogers et al. entitled: “Web Browser System”, and in U.S. Pat. No. 6,230,171 to Pacifici et al. entitled: “Markup System for Shared HTML Documents”, which are all incorporated in their entirety for all purposes as if fully set forth herein. The architecture and functionalities of a web browser are further described in a publication entitled: “Architecture and evolution of the modern web browser” by Alan Grosskurth and Michael W. Godfrey of the University of Waterloo in Canada, dated Jun. 20, 2006, in a publication by Alan Grosskurth and Michael W. Godfrey of the University of Waterloo in Canada entitled: “A Reference Architecture for web browsers” (downloaded May 20, 2015), in an International Business Machines (IBM) Corporation 1996 Open Blueprint publication G325-6589-00 entitled: “Web Browser Resource Manager”, and in a paper by Adam Barth, Collin Jackson, Charles Reis, and the Google Chrome Team (downloaded May 20, 2015) entitled: “The Security Architecture of the Chromium Browser”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
A currently popular web browser is the Internet Explorer (formerly Microsoft Internet Explorer and Windows Internet Explorer, commonly abbreviated IE or MSIE) from Microsoft Corporation, headquartered in Redmond, Wash., U.S.A., which is a series of graphical web browsers developed by Microsoft and included as part of the Microsoft Windows line of operating systems. The Internet Explorer 8 is described, for example, in Microsoft 2009 publication entitled: “Step by Step Tutorials for Microsoft Internet Explorer 8 Accessibility Options”, which is incorporated in its entirety for all purposes as if fully set forth herein. Another popular web browser is the Google Chrome which is a freeware web browser developed by Google, headquartered in Googleplex, Mountain View, Calif., U.S.A. Google Chrome aims to be secure, fast, simple, and stable, providing strong application performance and JavaScript processing speed.
A mobile browser, also called a microbrowser, minibrowser, or Wireless Internet Browser (WIB), is a web browser designed for use on a mobile device such as a mobile phone or PDA. Mobile browsers are optimized to display Web content most effectively for small screens on portable devices. Mobile browser software must be small and efficient to accommodate the low memory capacity and low-bandwidth of wireless handheld devices. Some mobile browsers can handle more recent technologies like CSS 2.1, JavaScript, and Ajax. Websites designed for access from these browsers are referred to as wireless portals, or collectively as the Mobile Web.
The mobile browser typically connects via cellular network, Wireless LAN, or via other wireless networks using standard HTTP over TCP/IP, and displays web pages written in HTML, XHTML Mobile Profile (WAP 2.0), or WML (which evolved from HDML). WML and HDML are stripped-down formats suitable for transmission across limited bandwidth, and wireless data connection called WAP. WAP 2.0 specifies XHTML Mobile Profile plus WAP CSS, subsets of the W3C's standard XHTML and CSS with minor mobile extensions. Some mobile browsers are full-featured Web browsers capable of HTML, CSS, ECMAScript, as well as mobile technologies such as WML, i-mode HTML, or cHTML. To accommodate small screens, some mobile browsers use Post-WIMP interfaces. An example of a mobile browser is Safari, which is a mobile web browser developed by Apple Inc. (headquartered in Apple Campus, Cupertino, Calif., U.S.A), included with the OS X and iOS operating systems, and described in Apple publication entitled: “Safari Web Content Guide”, dated March 2014, which is incorporated in its entirety for all purposes as if fully set forth herein.
A multitasking is a method where multiple tasks (also known as processes or programs) are performed during the same period of time, and executed concurrently (in overlapping time periods, new tasks starting before others have ended) instead of sequentially (one completing before the next starts). The tasks share common processing resources, such as a CPU and main memory. Multitasking does not necessarily mean that multiple tasks are being executed, exactly at the same instant. In other words, multitasking does not imply parallelism, but it does mean that more than one task can be part-way through execution at the same time, and more than one task is advancing over a given period of time.
In the case of a computer with a single CPU, only one task is said to be running at any point in time, meaning that the CPU is actively executing instructions for that task. Multitasking solves the problem by scheduling which task may be the one running at any given time, and when another waiting task gets its turn. The act of reassigning a CPU from one task to another one is called a context switch. When context switches occur frequently enough, the illusion of parallelism is achieved. Even on computers with more than one CPU (called multiprocessor machines) or more than one core in a given CPU (called multicore machines), where more than one task can be executed at a given instant (one per CPU or core), multitasking allows many more tasks to be run than the number of available CPUs.
Operating systems may adopt one of many different scheduling strategies. In multiprogramming systems, the running task keeps running until it performs an operation that requires waiting for an external event (e.g. reading from a tape) or until the computer's scheduler forcibly swaps the running task out of the CPU. Multiprogramming systems are designed to maximize CPU usage. In time-sharing systems, the running task is required to relinquish the CPU, either voluntarily or by an external event such as a hardware interrupt. Time sharing systems are designed to allow several programs to execute simultaneously. In real-time systems, some waiting tasks are guaranteed to the CPU when an external event occurs. Real time systems are designed to control mechanical devices such as industrial robots, which require timely processing.
Multiprocessing is the use of two or more processors or Central Processing Units (CPUs) within a single computer system, typically combined with the ability to allocate tasks between them. In order to process programs simultaneously, the multiple processors commonly share main memory and peripherals. In a multiprocessing system, all CPUs may be equal, or some may be reserved for special purposes. A combination of hardware and operating system software design considerations determine the symmetry (or lack thereof) in a given system. For example, hardware or software considerations may require that only one particular CPU respond to all hardware interrupts, whereas all other work in the system may be distributed equally among CPUs; or execution of kernel-mode code may be restricted to only one particular CPU, whereas user-mode code may be executed in any combination of processors. Systems that treat all CPUs equally are called symmetric multiprocessing (SMP) systems. In systems where all CPUs are not equal, system resources may be divided in a number of ways, including Asymmetric Multiprocessing (ASMP), Non-Uniform Memory Access (NUMA) multiprocessing, and clustered multiprocessing.
In multiprocessing, the processors are typically used to execute a single sequence of instructions in multiple contexts (single-instruction, multiple-data or SIMD, often used in vector processing), multiple sequences of instructions in a single context (multiple-instruction, single-data or MISD, used for redundancy in fail-safe systems and sometimes applied to describe pipelined processors or hyper-threading), or multiple sequences of instructions in multiple contexts (multiple-instruction, multiple-data or MIMD). Tightly coupled multiprocessor systems contain multiple CPUs that are connected at the bus level, and may have access to a central shared memory (SMP or UMA), or may participate in a memory hierarchy with both local and shared memory (NUMA). Chip multiprocessors, also known as multi-core computing, involves more than one processor placed on a single chip and can be thought of the most extreme form of tightly-coupled multiprocessing. Loosely coupled multiprocessor systems (often referred to as clusters) are based on multiple standalone single, or dual processor commodity computers interconnected via a high-speed communication system (Gigabit Ethernet is common). Tightly-coupled systems perform better and are physically smaller than loosely-coupled systems, but have historically required greater initial investments and may depreciate rapidly. Nodes in a loosely-coupled system are usually inexpensive commodity computers and can be recycled as independent machines upon retirement from the cluster.
Filter driver. A filter driver is a Microsoft Windows compatible driver that extends or modifies the function of peripheral devices, or supports a specialized device in a personal computer, and commonly relates to a driver, program, or module that is inserted into the existing driver stack to perform some specific function, while not affecting the normal working of the existing driver stack in any major way. Any number of filter drivers can be added to Windows, where upper-level filter drivers sit above the primary driver for the device (the function driver), while lower level filter drivers sit below the function driver and above a bus driver. Filter drivers may work on a certain brand of devices such as a mouse or keyboard, or they may perform some operation on a class of devices, such as any mouse or any keyboard. A filter driver may be developed using the guide entitled: “Filter Driver Development Guide” Version 1.0a by Microsoft Corporation, dated 2004, which is incorporated in its entirety for all purposes as if fully set forth herein.
Hook. A hook (also known as a hook procedure or hook function) is a mechanism by which an application can intercept events, such as messages, mouse actions, and keystrokes, and generally refers to a function provided by a software application that receives certain data before the normal or intended recipient of the data. The hook function can thus examine or modify certain data before passing on the data. The hook function allows a software application to examine, or modify data before the data is passed to the intended recipient. A function that intercepts a particular type of event is known as a hook procedure. The hook procedure can act on each event it receives, and then modify or discard the event. The term ‘hooking’ is used herein to include, but not limited to, a range of techniques used to alter or augment the behavior of an operating system, applications, or other software components by intercepting function calls, messages, or events passed between software components. A code that handles such intercepted function calls, events or messages is called a “hook”. Hooking is used for many purposes, including debugging and extending functionality.
Examples may include intercepting keyboard or mouse event messages before they reach an application, or intercepting operating system calls in order to monitor behavior, or modify the function of an application or another component. It is also widely used in benchmarking programs, for example frame rate measuring in 3D games, where the output and input are done through hooking. Hooking is described in the presentations by High-Tech Bridge SA and titled: “Userland Hooking in Windows” dated August 2011, and “Inline Hooking in Windows” dated September 2011, both by Brian Mariani, and both incorporated in their entirety for all purposes as if fully set forth herein.
Physical modification. A hooking may be achieved by physically modifying an executable or library before an application is run through techniques of reverse engineering. This is typically used to intercept function calls to either monitor or replace them entirely. For example, by using a disassembler, the entry point of a function within a module can be found. It can then be altered to dynamically load some other library module and then have it execute desired methods within that loaded library. If applicable, altering an import table of an executable is another related approach by which hooking can be achieved. This table can be modified to load any additional library modules as well as changing what external code is invoked when a function is called by an application. An alternate method for achieving the function of hooking is by intercepting function calls through a wrapper library. When creating a wrapper, you make your own version of a library that an application loads, with all the same functionality of the original library that it will replace, so all the functions that are accessible, are essentially the same between the original and the replacement. This wrapper library can be designed to call any of the functionality from the original library, or replace it with an entirely new set of logic.
Runtime modification. Operating systems and software may provide the means to easily insert event hooks at runtime, as long as the process inserting the hook is granted enough permission to do so. Microsoft Windows allows inserting hooks that can be used to process or modify system events and application events for dialogs, scrollbars, and menus, as well as other items. It also allows a hook to insert, remove, process, or modify keyboard and mouse events. Linux provides another example where hooks can be used in a similar manner to process network events within the kernel through NetFilter. When such functionality is not provided, a special form of hooking employs intercepting library function calls that are made by a process. Function hooking is implemented by changing the very first few code instructions of the target function to jump to an injected code. Alternatively, on systems using the shared library concept, the interrupt vector table or the import descriptor table can be modified in memory.
A hook chain is a list of pointers to special, application-defined callback functions called hook procedures. When a message occurs that is associated with a particular type of hook, the operating system passes the message to each hook procedure referenced in the hook chain, one after the other. The action of a hook procedure can depend on the type of hook involved. For example, the hook procedures for some types of hooks can only monitor messages, while others can modify the messages, or stop their progress through the chain, restricting them from reaching the next hook procedure, or a destination window.
Plug-in. A plug-in (or ‘plugin’, ‘extension’, or ‘add-on’/‘addon’) is a software component that adds a specific feature to an existing software application, such as enabling customization. The common examples are the plug-ins used in web browsers to add new features such as search-engines or virus scanners, or the ability to utilize a new file type such as a new video format. An ‘Add-on’ (or ‘addon’) is the general term for what enhances an application, and comprises snap-in, plug-in, theme, and skin. An extension add-on tailors the core features of an application by adding an optional module, whereas a plug-in add-on would tailor the outer layers of an application to personalize functionality. A theme or a skin add-on is a preset package containing additional or changed graphical appearance details, achieved by the use of a Graphical User Interface (GUI) that can be applied to a specific software and websites to suit the purpose, topic, or tastes of different users to customize the look and feel of a piece of computer software or an operating system front-end GUI (and window managers).
Typically, the host application provides services which the plug-in can use, including a way for plug-ins to register themselves with the host application, and protocol for the exchange of data with plug-ins. Plug-ins depend on the services provided by the host application and do not usually work by themselves. Conversely, the host application operates independently of the plug-ins, making it possible for end-users to add and update plug-ins dynamically without needing to make changes to the host application. The term ‘plug-in’ is used herein to include, but not limited to, a software extension, which is software that serves to extend the capabilities of, or data available to existing software application; it becomes included in the program. Therefore, after integration, extensions can be seen as part of the browser itself, tailored from a set of optional modules.
IPC. An Inter-Process Communication (IPC) (also be referred to as inter-thread communication and inter-application communication) is a set of methods for the exchange of data between multiple threads, in one or more processes. IPC methods may use message passing, synchronization, shared memory, and Remote Procedure Calls (RPC). It provides an environment that allows process cooperation, and may be used for providing information sharing, computational speedup, modularity, convenience, and privilege separation. In the Windows operating system environment, the IPC provides mechanisms for facilitating communications and data sharing between processes or applications.
Common IPC methods include file sharing, where a record (or any other information) stored on disk (or any other memory) can be accessed by name by any process; a signal which is an asynchronous notification sent to a process, or to a specific thread within the same process in order to notify it of an event that occurred; a socket which is a data stream sent over a network interface, either to a different process on the same computer or on another computer, such as Internet sockets; a pipe (or pipeline) which is a two-way data stream interfaced through standard input and output and is read character by character, commonly used in Unix-like computer operating systems; message queues which are anonymous data stream similar to the pipe that stores and retrieves information in packets, providing an asynchronous communications protocol; a semaphore which is a variable or abstract data type that is used for controlling access to a common resource; a shared memory which is a memory that may be simultaneously accessed by multiple programs with an intent to provide communication among them, or avoid redundant copies, such as where one process creates an area in RAM which other processes can access; and memory mapped file, where a file that is physically present on-disk, but can also be a device, shared memory object, or other resource that the operating system can reference through a file descriptor. Few IPC mechanisms are described in Chapter 9 of the Marko Vuskovic publication ‘Operating Systems’, entitled: “INTERPROCESS COMMUNICATION”, which is incorporated in its entirety for all purposes as if fully set forth herein.
The Windows operating system supports IPC mechanisms such as a clipboard, where the clipboard acts as a central depository for data sharing among applications, so when a user performs a cut or copy operation in an application, the application puts the selected data on the clipboard in one or more standard, or application-defined formats, and any other application can then retrieve the data from the clipboard, choosing from the available formats that it understands; using Component Object Model (COM), where applications that use Object Linking and Embedding (OLE) manage compound documents can be used to call on other applications for data editing; Using Data Copy enabling an application to send information to another application using the WM_COPYDATA message; DDE protocol that enables applications to exchange data in a variety of formats; and mailslots providing one-way communication where processes write messages to their mailslot.
Browser extension. A browser extension is a computer program that extends the functionality of a web browser in some way. Extensions can be created through the use of web technologies such as HTML, JavaScript, and CSS. Browser extensions can also improve the user interface of the web browser without directly affecting the viewable content of a web page, which can be achieved through a variety of add-ons, such as toolbars and plug-ins. The syntax for extensions may differ from browser to browser, or at least enough different that an extension working on a browser does not work on another one.
Plug-ins add specific abilities into browsers using Application Programming Interfaces (APIs) allowing third parties to create plug-ins that interact with the browser. The original API was NPAPI, but subsequently Google introduced the PPAPI interface in Chrome. In addition, plug-ins allow browser extensions to perform tasks such as blocking ads, creating a secure online connection, and adding applications to a browser. Common browser plug-ins include the Adobe Flash Player, the QuickTime Player, and the Java plug-in, which can launch a user-activated Java applet on a web page, and the applet is then executed within a Java Virtual Machine (JVM) in a process separate from the web browser itself.
Sockets. A socket (a.k.a. ‘network socket’) is an endpoint of an IPC flow across a computer network. In the case the communication is based on IP (Internet Protocol), the network sockets are referred to as Internet sockets. A socket API is an application programming interface (API), usually provided by the operating system that allows application programs to control and use network sockets. Internet socket APIs are usually based on the Berkeley sockets standard. A socket address is the combination of an IP address and a port number, similar to one end of a telephone connection in the combination of a phone number and a particular extension. Based on this address, internet sockets deliver incoming data packets to the appropriate application process or thread. Sockets are further described in a University of Toronto, Department of Computer Science presentation entitled: “Tutorial on Socket Programming” by Amin Tootoonchian, downloaded on August 2014, and in the SAS Institute Inc. SHARE Session 5958 tutorial ‘C Socket Programming Tutorial’ entitled: “Writing Client/Server Programs in C Using Sockets (A Tutorial) Part 1”, by Greg Granger, dated February of 1998, which are both incorporated in their entirety for all purposes as if fully set forth herein.
An Internet socket is characterized by a unique combination of a Local socket address (Local IP address and port number), remote socket address (used for established TCP sockets), and the used Protocol, typically a transport protocol (e.g., TCP, UDP, raw IP, or others). Within the operating system and the application that created a socket, a socket is referred to by a unique integer value called a socket descriptor. The operating system forwards the payload of incoming IP packets to the corresponding application by extracting the socket address information from the IP and transport protocol headers, and stripping the headers from the application data.
Several Internet socket types are available, such as Datagram sockets, also known as connectionless sockets, which use User Datagram Protocol (UDP), Stream sockets, also known as connection-oriented sockets, which use Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP), and Raw sockets (or Raw IP sockets), typically available in routers and other network equipment. Here the transport layer is bypassed, and the packet headers are made accessible to the application. Other socket types are implemented over other transport protocols, such as Systems Network Architecture (SNA). Communicating local and remote sockets are called socket pairs. Each socket pair is described by a unique 4-tuple consisting of source and destination IP addresses and port numbers, i.e. of local and remote socket addresses. In the TCP case, each unique socket pair 4-tuple is assigned a socket number, while in the UDP case each unique local socket address is assigned a socket number.
The socket is primarily a concept used in the Transport Layer of the Internet model. Networking equipment such as routers and switches, do not require implementations of the Transport Layer, as they operate on the Link Layer level (switches) or at the Internet Layer (routers). However, stateful network firewalls, network address translators, and proxy servers keep track of active socket pairs. Also in fair queuing, layer 3 switching and quality of service (QoS) support in routers, packet flows may be identified by extracting information about the socket pairs. Raw sockets are typically available in network equipment and are used for routing protocols such as IGRP and OSPF, and in Internet Control Message Protocol (ICMP).
The amount of data transferred during a given period in commonly referred to as ‘bandwidth’ (BW) or ‘bit-rate’, which is the number of bits that are conveyed or processed per unit of time. The bit rate is quantified using the bits per second unit (symbol bit/s or b/s), often in conjunction with an SI prefix such as kilo- (1 Kbit/s=1000 bit/s), mega- (1 Mbit/s=1000 Kbit/s), giga- (1 Gbit/s=1000 Mbit/s) or tera- (1 Tbit/s=1000 Gbit/s). The non-standard abbreviation bps is often used to replace the standard symbol bit/s, so that, for example, “1 Mbps” (or 1 Mb/s) is used to mean one million bits per second. One byte per second (1 B/s) corresponds to 8 bit/s.
Latency is typically defined as a time interval between the stimulation and the response, or from a more general point of view, as a time delay between the cause and the effect of some physical change in the system being observed. Network-related latency, such as in a packet-switched network, is measured either one-way (the time from the source sending a packet to the destination receiving it), or Round-Trip delay Time (RTT), referring to the one-way latency from source to destination plus the one-way latency from the destination back to the source, plus any delays at the destination, such as processing or other delays. Round-trip latency can be measured from a single point. Latency limits total bandwidth in reliable two-way communication systems as described by the bandwidth-delay product, which refers to the product of a data link's capacity (in bits per second) and its end-to-end delay (in seconds). The result, an amount of data measured in bits (or bytes), is equivalent to the maximum amount of data on the network circuit at any given time, i.e., data that has been transmitted but not yet acknowledged. Sometimes it is calculated as the data link's capacity multiplied by its round trip time. A network with a large bandwidth-delay product is commonly known as a Long Fat Network (LFN). As defined in IETF RFC 1072, a network is considered an LFN if its bandwidth-delay product is significantly larger than 105 bits (12500 bytes).
The Round-trip Delay Time (RTD) or Round-Trip Time (RTT) is the length of time it takes for a signal to be sent and to be received and processed at the destination node, plus the length of time it takes for an acknowledgment of that signal to be received. This time delay therefore, includes the propagation times between the two points of a signal. The signal is generally a data packet, and the RTT is also known as the ping time, where an internet user can determine the RTT by using the ping command. Network links with both a high bandwidth and a high RTT can have a very large amount of data (the bandwidth-delay product) “in flight” at any given time. Such “long fat pipes” require a special protocol design. One example is the TCP window scale option. The RTT was originally estimated in TCP by: RTT=(α·Old_RTT)+((1−α)·New_Round_Trip_Sample), where a is a constant weighting factor (0≤α<1). Choosing a value α close to 1 makes the weighted average immune to changes that last a short time (e.g., a single segment that encounters long delay). Choosing a value for a close to 0 makes the weighted average response to changes in delay very quickly. Once a new RTT is calculated, it is entered into the above equation to obtain an average RTT for that connection, and the procedure continues with every new calculation. The RTT may be measured as described in IETF 1323, and may be estimated by using a method described in IETF RFC 6323, which are both incorporated in their entirety for all purposes as if fully set forth herein.
An estimation of RTT for messages using TCP may use Karn's Algorithm, described by Karn Phil and Craig Partridge in ACM SIGCOMM '87—Computer Communication Review publication, entitled: “Improving Round-Trip Time Estimates in Reliable Transport Protocols”, which is incorporated in its entirety for all purposes as if fully set forth herein. The round trip time is estimated as the difference between the time that a segment was sent and the time that its acknowledgment was returned to the sender, but when packets are re-transmitted, there is an ambiguity: the acknowledgment may be a response to the first transmission of the segment or to a subsequent re-transmission. Karn's Algorithm ignores re-transmitted segments when updating the round-trip time estimate. Round trip time estimation is based only on unambiguous acknowledgments, which are acknowledgments for segments that were sent only once.
Many software platforms provide a service called ‘ping’ that can be used to measure round-trip latency. Ping performs no packet processing; it merely sends a response back when it receives a packet (i.e., performs a no-op), thus it is a first rough way of measuring latency. Ping operates by sending Internet Control Message Protocol (ICMP) echo requesting packets to the target host, and waiting for an ICMP response. During this process it measures the time from transmission to reception (round-trip time), and records any packet loss. The results of the test are printed in a form of a statistical summary of the response packets received, including the minimum, maximum, and the mean round-trip times, and sometimes the standard deviation of the mean.
The Transmission Control Protocol/Internet Protocol (TCP/IP) suite normally used on the Internet has included an Internet Message Control Protocol (ICMP) that is commonly used in echo testing or ping and trace route applications. In general, the Internet standard ‘ping’ or ‘ICMP echo’ has a request/response format, wherein one device sends an ICMP echo request and another device responds to a received ICMP echo request with a transmitted ICMP echo response. Normally, IP devices are expected to implement the ICMP as part of the support for IP, to be able to use ICMP for testing. Internet RFC 792, entitled “Internet Control Message Protocol: DARPA Internet Program Protocol Specification”, which is incorporated in its entirety for all purposes as if fully set forth herein, at least partially describes the behavior of ICMP. The ICMP echo message has a type field, a code field, a checksum field, an identifier field, a sequence number field, and a data field. According to RFC 792: “The data received in the echo message must be returned in the echo reply message”. Thus, an RFC compliant ping responders or an ICMP echo reply message responders are supposed to copy the received data field in an echo request message directly into the data field of the transmitted echo response message.
A newer version of ICMP known as ICMP version 6 or ICMPv6 as described at least partially in RFCs 1885 and 2463, which are both entitled “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, which are both incorporated in their entirety for all purposes as if fully set forth herein. According to RFC 2463, “Every [IPv6] node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies. An IPv6 node SHOULD also implement an application-layer interface for sending Echo Requests and receiving Echo Replies, for diagnostic purposes.”. Thus, responding to ICMP echo requests normally is a necessary function in supporting IPv4 and/or IPv6 standards. The ICMPv6 RFCs 1885 and 2463 goes on to specify that the data field of an ICMP echo response contains the “data from the invoking Echo Request message.” Therefore, both ICMP and ICMP v6 associated with IPv4 and IPv6, respectively, specify that the data field in an ICMP echo reply message is to essentially contain a copy of the data received in the corresponding ICMP echo request message.
Moreover, the ICMP echo protocol is basically a two-way echo in which one initiating device and/or process starts the communication by transmitting an echo request message, which may be then received by an echo responder process. The echo responder process, generally located on another device, receives the echo request message and responds with an echo reply back to the initiating process. Once the initiating device and/or process receives the response or times out waiting for the response, the two-way echo exchange of messages is complete. Although the echo request and echo response normally are performed between processes on two different devices, one skilled in the art will be aware that a device can ping its own IP address implying that the echo request and echo responder reply processes are on the same device. In addition, the loopback address of network 127.0.0.0 in IPv4 can be used to allow a device to the loopback outbound echo request messages back into the device incoming echo request responder processes. IPv6 has a loopback functionality as well.
This copying of data exactly in the ICMP echo response is somewhat wasteful because the responder generally does not convey that much (if any) information back to the ICMP echo request initiating device. The initiating device can compute bit error rate (BER) statistics on the transmitted versus the received data field in ICMP echo packets. However, such physical layer related issues such as BER statistics normally are not as relevant for network layer IP datagrams that already include various error control code mechanisms. The device running the responding process may communicate information to the device running the initiating process by having the device running the original responding process initiate its own echo request and waiting for an echo response from the original initiating device. Such a solution results in four packets, with a first echo request from a local device responded to by a first echo response from a remote device, and with a second echo request from the remote device responded to by a second echo response from the local device.
An identifier and/or sequence number in ping packets generally has allowed the ping to be used by a device to determine the round-trip delay from the time an ICMP echo request packet is sent to the time corresponding to when an associated received ICMP echo request is received back at an initiating device. Furthermore, ping packets generally convey little or no information about the type of the device that initiated the ping. Although IPv4 has Type of Service (ToS) fields in the IP datagram, these fields have become more important as the services used over the Internet, and networks using Internet technology have grown from basic computer data communication to further include real-time applications such as voice and/or video. Various Type of Service (ToS) in IPv4 and IPv6 have been used in implementing various (Quality of Service) QoS characteristics that are defined for different classes of service and/or Service Level Agreements (SLAs).
Caching. A system and method for increasing cache size by performing the steps of: categorizing storage blocks within a storage device as within a first category of storage blocks if the storage blocks that are available to the system for storing data when needed; categorizing storage blocks within the storage device as within a second category of storage blocks if the storage blocks contain application data therein; and categorizing storage blocks within the storage device as within a third category of storage blocks if the storage blocks are storing cached data and are available for storing application data if no first category of storage blocks are available to the system, is described in U.S. Pat. No. 8,135,912 to Shribman et al. entitled: “System and Method of Increasing Cache Size”, which is incorporated in its entirety for all purposes as if fully set forth herein. A system for resolving Domain Name System (DNS) queries that contains a communication device for resolving DNS queries, wherein the communication device further contains a memory and a processor that is configured by the memory, a cache storage for use by the communication device, and a network of authoritative domain name servers, where in a process of the communication device looking up a DNS request within the cache storage, if the communication device views an expired DNS entry within the cache storage, the communication device continues the process of looking up the DNS request in the cache storage while, in parallel, sending out a concurrent DNS request to an authoritative domain name server that the expired DNS entry belongs to, is described in U.S. Pat. No. 8,671,221 to the same inventors as this application, entitled: “Method and System for Increasing Speed of Domain Name System Resolution within a Computing Device”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Systems and methods of storing previously transmitted data and using it to reduce bandwidth usage and accelerate future communications, and using algorithms to identify long compression history matches. A network device that may improve compression efficiency and speed is described in U.S. Pat. No. 7,865,585 to Samuels et al., entitled: “Systems and Methods for Providing Dynamic Ad Hok Proxy-Cache Hierarchies”, which is incorporated in its entirety for all purposes as if fully set forth herein. Further, a method and system for accelerating the receipt of data in a client-to-client network described in U.S. Pat. No. 7,203,741 to Marco et al., entitled: “Method and System for Accelerating Receipt of Data in a Client-to-Client Network”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Cache eviction schemes. Cache eviction schemes, also known as cache algorithms, cache replacement algorithms, or cache replacement policies, are optimizing instructions or algorithms that a computer program or a hardware-maintained structure can follow in order to optimally manage a cache of information stored on the computer. In particular, when the cache is full, the algorithm must choose which items to discard to make room for the new ones. Memories inherently provide finite and limited storage space, so when the storage becomes full, stored elements are evicted according to an eviction scheme in order to avoid overflow. The eviction scheme is usually serving two primary figures of merit of a cache: The latency, and the hit rate. The “hit ratio” of a cache describes how often a searched-for item is actually found in the cache, and more efficient replacement policies keep track of more usage information in order to improve the hit rate (for a given cache size). The “latency” of a cache describes how long after requesting a desired item the cache can return that item (when there is a hit). Faster replacement strategies typically keep track of less usage information or, in the case of direct-mapped cache, no information—to reduce the amount of time required to update that information. Commonly an eviction scheme strategy is a compromise between hit rate and latency.
Cache eviction schemes are described in a paper by Zhifeng Cheny, Yuanyuan Zhouy, (of Department of Computer Science, University of Illinois at Urbana-Champaign) and Kai Li (of Department of Computer Science, Princeton University) (downloaded from the Internet on 2-2016) entitled: “Eviction Based Cache Placement for Storage Caches”, in an article published 2014 by the IEEEE Computer Society [0018-9162/04] authored by Nimrod Megiddo and Dharmendra S. Modha (of IBM Almaden Research Center) entitled: “Outperforming LRU with an Adaptive Replacement Cache Algorithm”, in an article published in the Proceedings of the International Conference on Computer Design, San Jose, Oct. 2-5, 2005 by Mazen Kharbutli and Yan Solihin (both of Department of Electrical and Computer Engineering, North Carolina State University) entitled: “Counter-Based Cache Replacement Algorithms”, and in a paper (downloaded 2-2016 from the Internet) by Keqiu Li, Takashi Nanya, Hong Shen, Francis Y. L. Chin, and Weishi Zhang entitled: “An Efficient Cache Replacement Algorithm for Multimedia Object Caching”, which are all incorporated in their entirety for all purposes as if fully set forth herein. Examples of cache eviction schemes include Beladys algorithm, Least Recently Used (LRU), Most Recently Used (MRU), Pseudo-LRU (PLRU), Random Replacement (RR), Least Frequently Used (LFU), and First-In-First-Out (FIFO).
Beladys algorithm. The most efficient caching algorithm would be to always discard the information that will not be needed for the longest time in the future. This optimal result is referred to as Bélády's optimal algorithm or the clairvoyant algorithm. Since it is generally impossible to predict how far in the future information will be needed, this is generally not implementable in practice. The practical minimum can be calculated only after experimentation, and one can compare the effectiveness of the actually chosen cache algorithm.
Least Recently Used (LRU). This scheme involves discarding the least recently used items first. This algorithm requires keeping track of what was used and when, which is expensive if one wants to make sure the algorithm always discards the least recently used item. General implementations of this technique require keeping “age bits” for cache-lines and track the “Least Recently Used” cache-line based on age-bits. In such an implementation, every time a cache-line is used, the age of all other cache-lines changes. This is the default and is a variation on Least Frequently Used, where the oldest element is the Less Recently Used (LRU) element. The last used timestamp is updated when an element is put into the cache or an element is retrieved from the cache with a get call.
Most Recently Used (MRU). This scheme involves discarding the most recently used items first. MRU cache algorithms may have more hits than LRU due to their tendency to retain older data. MRU algorithms are most useful in situations where the older an item is, the more likely it is to be accessed.
Random Replacement (RR). Randomly selects a candidate item and discards it to make space when necessary. This algorithm does not require keeping any information about the access history.
Least Frequently Used (LFU). For each call on an element, the number of hits is updated. When a put call is made for a new element (and assuming that the max limit is reached) the element with least number of hits, the Least Frequently Used element, is evicted. If cache element use follows a Pareto distribution, this algorithm may give better results than LRU. LFU takes a random sample of the elements and evicts the smallest.
First-In-First-Out (FIFO). In this scheme, elements are evicted in the same order as they come in. When a put call is made for a new element (and assuming that the max limit is reached for the memory store) the element that was placed first (First-In) in the store is the candidate for eviction (First-Out). This algorithm is typically used if the use of an element makes it less likely to be used in the future.
Database. A database is an organized collection of data, typically managed by a DataBase Management System (DBMS) that organizes the storage of data and performs other functions such as the creation, maintenance, and usage of the database storage structures. The data is typically organized to model aspects of reality in a way that supports processes requiring information. Databases commonly also provide users with a user interface and front-end that enables the users to query the database, often in complex manners that require processing and organization of the data. The term “database” is used herein to refer to a database, or to both a database and the DBMS used to manipulate it. Database management systems (DBMS) are typically computer software applications that interact with the user, other applications, and the database itself to capture and analyze data, typically providing various functions that allow entry, storage and retrieval of large quantities of information, as well as providing ways to manage how that information is organized. A general-purpose DBMS is designed to allow the definition, creation, querying, update, and administration of databases. Examples of DBMSs include MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase and IBM DB2. Database technology and application is described in a document published by Telemark University College entitled “Introduction to Database Systems”, authored by Hans-Petter Halvorsen (dated 2014 Mar. 3), which is incorporated in its entirety for all purposes as if fully set forth herein.
SQL. Structured Query Language (SQL) is a widely-used programming language for working with relational databases, designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS). SQL consists of a data definition language and a data manipulation language. The scope of SQL includes data insert, query, update and delete, schema creation and modification, and data access control. Although SQL is often described as, and largely is, a declarative language (4GL), it also includes procedural elements. SQL is designed for querying data contained in a relational database, and is a set-based, declarative query language. The SQL is standardized as ISO/IEC 9075:2011 standard: “Information technology—Database languages—SQL”. The ISO/IEC 9075 standard is complemented by ISO/IEC 13249 standard: “SQL Multimedia and Application Packages” that defines interfaces and packages based on SQL. The aim is a unified access to typical database applications like text, pictures, data mining or spatial data. SQL is described in the tutorial entitled: “Oracle/SQL Tutorial” by Michael Gertz of the University of California, which is incorporated in its entirety for all purposes as if fully set forth herein.
Compression. Data compression, also known as source coding and bit-rate reduction, involves encoding information using fewer bits than the original representation. Compression can be either lossy, or lossless. Lossless compression reduces bits by identifying and eliminating statistical redundancy, so that no information is lost in lossless compression. Lossy compression reduces bits by identifying unnecessary information and removing it. The process of reducing the size of a data file is commonly referred to as a data compression. A compression is used to reduce resource usage, such as data storage space, or transmission capacity. Data compression is further described in a Carnegie Mellon University chapter entitled: “Introduction to Data Compression” by Guy E. Blelloch, dated Jan. 31, 2013, which is incorporated in its entirety for all purposes as if fully set forth herein.
In a scheme involving lossy data compression, some loss of information is acceptable. For example, dropping of a nonessential detail from a data can save storage space. Lossy data compression schemes may be informed by research on how people perceive the data involved. For example, the human eye is more sensitive to subtle variations in luminance than it is to variations in color. JPEG image compression works in part by rounding off nonessential bits of information. There is a corresponding trade-off between preserving information and reducing size. A number of popular compression formats exploit these perceptual differences, including those used in music files, images, and video.
Lossy image compression is commonly used in digital cameras, to increase storage capacities with minimal degradation of picture quality. Similarly, DVDs use the lossy MPEG-2 Video codec for video compression. In lossy audio compression, methods of psychoacoustics are used to remove non-audible (or less audible) components of the audio signal. Compression of human speech is often performed with even more specialized techniques, speech coding, or voice coding, is sometimes distinguished as a separate discipline from audio compression. Different audio and speech compression standards are listed under audio codecs. Voice compression is used in Internet telephony, for example, and audio compression is used for CD ripping and is decoded by audio player.
Lossless data compression algorithms usually exploit statistical redundancy to represent data more concisely without losing information, so that the process is reversible. Lossless compression is possible because most real-world data has statistical redundancy. The Lempel-Ziv (LZ) compression methods are among the most popular algorithms for lossless storage. DEFLATE is a variation on LZ optimized for decompression speed and compression ratio, and is used in PKZIP, Gzip and PNG. The LZW (Lempel-Ziv-Welch) method is commonly used in GIF images, and is described in IETF RFC 1951. The LZ methods use a table-based compression model where table entries are substituted for repeated strings of data. For most LZ methods, this table is generated dynamically from earlier data in the input. The table itself is often Huffman encoded (e.g., SHRI, LZX). Typical modern lossless compressors use probabilistic models, such as prediction by partial matching.
Lempel-Ziv-Welch (LZW) is an example of lossless data compression algorithm created by Abraham Lempel, Jacob Ziv, and Terry Welch. The algorithm is simple to implement, and has the potential for very high throughput in hardware implementations. It was the algorithm of the widely used Unix file compression utility compress, and is used in the GIF image format. The LZW and similar algorithms are described in U.S. Pat. No. 4,464,650 to Eastman et al. entitled: “Apparatus and Method for Compressing Data Signals and Restoring the Compressed Data Signals”, in U.S. Pat. No. 4,814,746 to Miller et al. entitled: “Data Compression Method”, and in U.S. Pat. No. 4,558,302 to Welch entitled: “High Speed Data Compression and Decompression Apparatus and Method”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Image/video. Any content herein may consist of, be part of, or include, an image or a video content. A video content may be in a digital video format that may be based on one out of: TIFF (Tagged Image File Format), RAW format, AVI, DV, MOV, WMV, MP4, DCF (Design Rule for Camera Format), ITU-T H.261, ITU-T H.263, ITU-T H.264, ITU-T CCIR 601, ASF, Exif (Exchangeable Image File Format), and DPOF (Digital Print Order Format) standards. An intraframe or interframe compression may be used, and the compression may be a lossy or a non-lossy (lossless) compression, that may be based on a standard compression algorithm, which may be one or more out of JPEG (Joint Photographic Experts Group) and MPEG (Moving Picture Experts Group), ITU-T H.261, ITU-T H.263, ITU-T H.264 and ITU-T CCIR 601.
DHCP. The Dynamic Host Configuration Protocol (DHCP) is a standardized networking protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services. With DHCP, network elements request IP addresses and networking parameters automatically from a DHCP server, reducing the need for a network administrator or a user to configure these settings manually.
DHCP is typically used by network elements for requesting Internet Protocol parameters, such as an IP address from a network server, and is based on the client-server model. When a network element connects to a network, its DHCP client software in the operating system sends a broadcast query requesting necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers. On receiving a request, the server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network, and the period for which the allocation (lease) is valid. A host typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When an assignment is refreshed by the client computer, it initially requests the same parameter values, and may be assigned a new address by the server, based on the assignment policies set by administrators.
Depending on implementation, the DHCP server may have three methods of allocating IP-addresses: (a) Dynamic allocation, where a network administrator reserves a range of IP addresses for DHCP, and each client computer on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed. (b) Automatic allocation, where the DHCP server permanently assigns an IP address to a requesting client from the range defined by the administrator. This is similar to dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had. (c) Static allocation, where the DHCP server allocates an IP address based on a preconfigured mapping to each client's MAC address.
DHCP used for Internet Protocol version 4 (IPv4) is described in IETF RFC 2131, entitled “Dynamic Host Configuration Protocol”, and DHCP for IPv6 is described IETF RFC 3315, entitled: “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, both incorporated in their entirety for all purposes as if fully set forth herein. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols. For IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv4 hosts may also use link-local addressing to achieve operation restricted to the local network link.
The DHCP protocol employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations, which are the same as for the BOOTP protocol. The UDP port number 67 is the destination port of a server, and the UDP port number 68 is used by the client. DHCP operations fall into four phases: server discovery, IP lease offer, IP request, and IP lease acknowledgment. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgment. The DHCP protocol operation begins with clients broadcasting a request. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via a UDP unicast, since the client already has an established IP address at that point.
Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities, and translates easily memorized domain names to the numerical IP addresses needed for locating computer services and devices worldwide. The DNS is described, for example, in the IETF RFC 3467 entitled: “Role of the Domain Name System (DNS)”, in the IETF RFC 6195 entitled: “Domain Name System (DNS) LANA Considerations”, and in the IETF RFC 1591 entitled: “Domain Name System Structure and Delegation”, which are incorporated in their entirety for all purposes as if fully set forth herein.
Video. The term ‘video’ typically pertains to numerical or electrical representation or moving visual images, commonly referring to recording, reproducing, displaying, or broadcasting the moving visual images. Video, or a moving image in general, is created from a sequence of still images called frames, and by recording and then playing back frames in quick succession, an illusion of movement is created. Video can be edited by removing some frames and combining sequences of frames, called clips, together in a timeline. A Codec, short for ‘coder-decoder’, describes the method in which video data is encoded into a file and decoded when the file is played back. Most video is compressed during encoding, and so the terms codec and compressor are often used interchangeably. Codecs can be lossless or lossy, where lossless codecs are higher quality than lossy codecs, but produce larger file sizes. Transcoding is the process of converting from one codec to another. Common codecs include DV-PAL, HDV, H.264, MPEG-2, and MPEG-4. Digital video is further described in Adobe Digital Video Group publication updated and enhanced March 2004, entitled: “A Digital Video Primer—An introduction to DV production, post-production, and delivery”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Digital video data typically comprises a series of frames, including orthogonal bitmap digital images displayed in rapid succession at a constant rate, measured in Frames-Per-Second (FPS). In interlaced video each frame is composed of two halves of an image (referred to individually as fields, two consecutive fields compose a full frame), where the first half contains only the odd-numbered lines of a full frame, and the second half contains only the even-numbered lines.
Many types of video compression exist for serving digital video over the internet, and on optical disks. The file sizes of digital video used for professional editing are generally not practical for these purposes, and the video requires further compression with codecs such as Sorenson, H.264, and more recently, Apple ProRes especially for HD. Currently widely used formats for delivering video over the internet are MPEG-4, Quicktime, Flash, and Windows Media. Other PCM based formats include CCIR 601 commonly used for broadcast stations, MPEG-4 popular for online distribution of large videos and video recorded to flash memory, MPEG-2 used for DVDs, Super-VCDs, and many broadcast television formats, MPEG-1 typically used for video CDs, and H.264 (also known as MPEG-4 Part 10 or AVC) commonly used for Blu-ray Discs and some broadcast television formats.
The term ‘Standard Definition’ (SD) describes the frame size of a video, typically having either a 4:3 or 16:9 frame aspect ratio. The SD PAL standard defines 4:3 frame size and 720×576 pixels, (or 768×576 if using square pixels), while SD web video commonly uses a frame size of 640×480 pixels. Standard-Definition Television (SDTV) refers to a television system that uses a resolution that is not considered to be either high-definition television (1080i, 1080p, 1440p, 4K UHDTV, and 8K UHD) or enhanced-definition television (EDTV 480p). The two common SDTV signal types are 576i, with 576 interlaced lines of resolution, derived from the European-developed PAL and SECAM systems, and 480i based on the American National Television System Committee NTSC system. In North America, digital SDTV is broadcast in the same 4:3 aspect ratio as NTSC signals with widescreen content being center cut. However, in other parts of the world that used the PAL or SECAM color systems, standard-definition television is now usually shown with a 16:9 aspect ratio. Standards that support digital SDTV broadcast include DVB, ATSC, and ISDB.
The term ‘High-Definition’ (HD) refers multiple video formats, which use different frame sizes, frame rates and scanning methods, offering higher resolution and quality than standard-definition. Generally, any video image with considerably more than 480 horizontal lines (North America) or 576 horizontal lines (Europe) is considered high-definition, where 720 scan lines is commonly the minimum. HD video uses a 16:9 frame aspect ratio and frame sizes that are 1280×720 pixels (used for HD television and HD web video), 1920×1080 pixels (referred to as full-HD or full-raster), or 1440×1080 pixels (full-HD with non-square pixels).
High definition video (prerecorded and broadcast) is defined by the number of lines in the vertical display resolution, such as 1,080 or 720 lines, in contrast to regular digital television (DTV) using 480 lines (upon which NTSC is based, 480 visible scanlines out of 525) or 576 lines (upon which PAL/SECAM are based, 576 visible scanlines out of 625). HD is further defined by the scanning system being progressive scanning (p) or interlaced scanning (i). Progressive scanning (p) redraws an image frame (all of its lines) when refreshing each image, for example 720p/1080p. Interlaced scanning (i) draws the image field every other line or “odd numbered” lines during the first image refresh operation, and then draws the remaining “even numbered” lines during a second refreshing, for example 1080i. Interlaced scanning yields greater image resolution if a subject is not moving, but loses up to half of the resolution, and suffers “combing” artifacts when a subject is moving. HD video is further defined by the number of frames (or fields) per second (Hz), where in Europe 50 Hz (60 Hz in the USA) television broadcasting system is common. The 720p60 format is 1,280×720 pixels, progressive encoding with 60 frames per second (60 Hz). The 1080i50/1080i60 format is 1920×1080 pixels, interlaced encoding with 50/60 fields, (50/60 Hz) per second.
Currently common HD modes are defined as 720p, 1080i, 1080p, and 1440p. Video mode 720p relates to frame size of 1,280×720 (W×H) pixels, 921,600 pixels per image, progressive scanning, and frame rates of 23.976, 24, 25, 29.97, 30, 50, 59.94, 60, or 72 Hz. Video mode 1080i relates to frame size of 1,920×1,080 (W×H) pixels, 2,073,600 pixels per image, interlaced scanning, and frame rates of 25 (50 fields/s), 29.97 (59.94 fields/s), or 30 (60 fields/s) Hz. Video mode 1080p relates to frame size of 1,920×1,080 (W×H) pixels, 2,073,600 pixels per image, progressive scanning, and frame rates of 24 (23.976), 25, 30 (29.97), 50, or 60 (59.94) Hz. Similarly, video mode 1440p relates to frame size of 2,560×1,440 (W×H) pixels, 3,686,400 pixels per image, progressive scanning, and frame rates of 24 (23.976), 25, 30 (29.97), 50, or 60 (59.94) Hz. Digital video standards are further described in a published 2009 primer by Tektronix® entitled: “A Guide to Standard and High-Definition Digital Video Measurements”, which is incorporated in its entirety for all purposes as if fully set forth herein.
MPEG-4. MPEG-4 is a method of defining compression of audio and visual (AV) digital data, designated as a standard for a group of audio and video coding formats, and related technology by the ISO/IEC Moving Picture Experts Group (MPEG) (ISO/IEC JTC1/SC29/WG11) under the formal standard ISO/IEC 14496—‘Coding of audio-visual objects’. Typical uses of MPEG-4 include compression of AV data for the web (streaming media) and CD distribution, voice (telephone, videophone) and broadcast television applications. MPEG-4 provides a series of technologies for developers, for various service-providers and for end users, as well as enabling developers to create multimedia objects possessing better abilities of adaptability and flexibility to improve the quality of such services and technologies as digital television, animation graphics, the World Wide Web and their extensions. Transporting of MPEG-4 is described in IETF RFC 3640, entitled: “RTP Payload Format for Transport of MPEG-4 Elementary Streams”, which is incorporated in its entirety for all purposes as if fully set forth herein. The MPEG-4 format can perform various functions such as multiplexing and synchronizing data, associating with media objects for efficiently transporting via various network channels. MPEG-4 is further described in a white paper published 2005 by The MPEG Industry Forum (Document Number mp-in-40182), entitled: “Understanding MPEG-4: Technologies, Advantages, and Markets—An MPEGIF White Paper”, which is incorporated in its entirety for all purposes as if fully set forth herein.
H.264. H.264 (a.k.a. MPEG-4 Part 10, or Advanced Video Coding (MPEG-4 AVC)) is a commonly used video compression format for the recording, compression, and distribution of video content. H.264/MPEG-4 AVC is a block-oriented motion-compensation-based video compression standard ITU-T H.264, developed by the ITU-T Video Coding Experts Group (VCEG) together with the ISO/IEC JTC1 Moving Picture Experts Group (MPEG), defined in the ISO/IEC MPEG-4 AVC standard ISO/IEC 14496-10-MPEG-4 Part 10-‘Advanced Video Coding’. H.264 is widely used by streaming internet sources, such as videos from Vimeo, YouTube, and the iTunes Store, web software such as the Adobe Flash Player and Microsoft Silverlight, and also various HDTV broadcasts over terrestrial (ATSC, ISDB-T, DVB-T or DVB-T2), cable (DVB-C), and satellite (DVB-S and DVB-S2). H.264 is further described in a Standards Report published in IEEE Communications Magazine, August 2006, by Gary J. Sullivan of Microsoft Corporation, entitled: “The H.264/MPEG4 Advanced Video Coding Standard and its Applications”, and further in IETF RFC 3984 entitled: “RTP Payload Format for H.264 Video”, which are both incorporated in their entirety for all purposes as if fully set forth herein.
Media Player. A media player is a computer program for playing multimedia files, and typically display standard media control icons (e.g., Play, Pause, and Stop buttons) known from physical devices such as tape recorders and CD players. Most operating systems embed a built-in media player. For example, Windows OS includes Windows Media Player, such as the Windows Media Player 11 described in Chapter 8 of the guide entitled: “MAXIMUM PC MICROSOFT WINDOWS VISTA EXPOSED” named “Mastering Windows Media Player 11”, which is incorporated in its entirety for all purposes as if fully set forth herein. Windows Media Player supports playback of audio, video and pictures, along with fast forward, reverse, file markers (if present), and variable playback speed (seek & time compression/dilation). It supports local playback, streaming playback with multicast streams, and progressive downloads, while items in a playlist can be skipped over temporarily at playback time without removing them from the playlist. The full keyboard-based operation is possible in the player. OS X includes QuickTime Player, such as QuickTime 7.3 described in a guide by Apple Computer, Inc. (2005) entitled: “QuickTime 7.3—User's Guide”, which is incorporated in its entirety for all purposes as if fully set forth herein. QuickTime is commonly bundled with OS X, and provides encoding and transcoding video and audio from one format to another, decoding video and audio, then sending the decoded stream to the graphics or audio subsystem for playback, and a “component” plug-in architecture for supporting additional 3rd-party codecs (such as DivX). Linux distributions include media players such as SMPlayer, Amarok, Audacious, Banshee, MPlayer, Rhythmbox, Totem, VLC, and xine. The VLC is described in a guide by the VideoLAN project entitled: “VLC user guide” by Henri Fallon et al., which is incorporated in its entirety for all purposes as if fully set forth herein. Media players are further described in U.S. Patent Application No. 2014/0201616 to Turner et al. entitled: “Cross-Platform Embeddable Media Player”, in U.S. Pat. No. 7,360,152 to Capps et al. entitled: “Universal Media Player”, and in U.S. Pat. No. 8,438,375 to Woodward entitled: “Configuring Media Player”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Streaming. Streaming media is multimedia that is constantly received by and presented to an end-user while being delivered by a provider. A client media player can begin playing the data (such as a movie) before the entire file has been transmitted. Distinguishing delivery method from the media distributed applies specifically to telecommunications networks, as most of the delivery systems are either inherently streaming (e.g., radio, television), or inherently non-streaming (e.g., books, video cassettes, audio CDs). Live streaming refers to content delivered live over the Internet, and requires a form of source media (e.g. a video camera, an audio interface, screen capture software), an encoder to digitize the content, a media publisher, and a content delivery network to distribute and deliver the content. Streaming content may be according to, compatible with, or based on, IETF RFC 3550 entitled: “RTP: A Transport Protocol for Real-Time Applications”, IETF RFC 4587 entitled: “RTP Payload Format for H.261 Video Streams”, or IETF RFC 2326 entitled: “Real Time Streaming Protocol (RTSP)”, which are all incorporated in their entirety for all purposes as if fully set forth herein. Video streaming is further described in a published 2002 paper by Hewlett-Packard Company (HP®) authored by John G. Apostolopoulos, Wai-Tian, and Susie J. Wee and entitled: “Video Streaming: Concepts, Algorithms, and Systems”, which is incorporated in its entirety for all purposes as if fully set forth herein.
An audio stream may be compressed using an audio codec such as MP3, Vorbis or AAC, and a video stream may be compressed using a video codec such as H.264 or VP8. Encoded audio and video streams may be assembled in a container bitstream such as MP4, FLV, WebM, ASF or ISMA. The bitstream is typically delivered from a streaming server to a streaming client using a transport protocol, such as MMS or RTP. Newer technologies such as HLS, Microsoft's Smooth Streaming, Adobe's HDS and finally MPEG-DASH have emerged to enable adaptive bitrate (ABR) streaming over HTTP as an alternative to using proprietary transport protocols. The streaming client may interact with the streaming server using a control protocol, such as MMS or RTSP.
Streaming media may use Datagram protocols, such as the User Datagram Protocol (UDP), where the media stream is sent as a series of small packets. However, there is no mechanism within the protocol to guarantee delivery, so if data is lost, the stream may suffer a dropout. Other protocols may be used, such as the Real-time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP) and the Real-time Transport Control Protocol (RTCP). RTSP runs over a variety of transport protocols, while the latter two typically use UDP. Another approach is HTTP adaptive bitrate streaming that is based on HTTP progressive download, designed to incorporate both the advantages of using a standard web protocol, and the ability to be used for streaming even live content is adaptive bitrate streaming. Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of each bit in the media stream, using a system of timeouts and retries, which makes them more complex to implement. Unicast protocols send a separate copy of the media stream from the server to each recipient, and are commonly used for most Internet connections.
Multicasting broadcasts the same copy of the multimedia over the entire network to a group of clients, and may use multicast protocols that were developed to reduce the server/network loads resulting from duplicate data streams that occur when many recipients receive unicast content streams, independently. These protocols send a single stream from the source to a group of recipients, and depending on the network infrastructure and type, the multicast transmission may or may not be feasible. IP Multicast provides the capability to send a single media stream to a group of recipients on a computer network, and a multicast protocol, usually Internet Group Management Protocol, is used to manage delivery of multicast streams to the groups of recipients on a LAN. Peer-to-peer (P2P) protocols arrange for prerecorded streams to be sent between computers, thus preventing the server and its network connections from becoming a bottleneck. HTTP Streaming—(a.k.a. Progressive Download; Streaming) allows for that while streaming content is being downloaded, users can interact with, and/or view it. VOD streaming is further described in a NETFLIX® presentation dated May 2013 by David Ronca, entitled: “A Brief History of Neflix Streaming”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Media streaming techniques are further described in a white paper published October 2005 by Envivio® and authored by Alex MacAulay, Boris Felts, and Yuval Fisher, entitled: “WHITEPAPER-IP Streaming of MPEG-4” Native RTP vs MPEG-2 Transport Stream”, in an overview published 2014 by Apple Inc.—Developer, entitled: “HTTP Live Streaming Overview”, and in a paper by Thomas Stockhammer of Qualcomm Incorporated entitled: “Dynamic Adaptive Streaming over HTTP—Design Principles and Standards”, in a Microsoft Corporation published March 2009 paper authored by Alex Zambelli and entitled: “IIS Smooth Streaming Technical Overview”, in an article by Liang Chen, Yipeng Zhou, and Dah Ming Chiu dated 10 Apr. 2014 entitled: “Smart Streaming for Online Video Services”, in Celtic-Plus publication (downloaded 2-2016 from the Internet) referred to as ‘H2B2VS D1 1 1 State-of-the-art V2.0.docx’ entitled: “H2B2VS D1.1.1 Report on the state of the art technologies for hybrid distribution of TV services”, and in a technology brief by Apple Computer, Inc. published March 2005 (Document No. L308280A) entitled: “QuickTime Streaming”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Progressive download. A progressive download is the transfer of digital media files from a server to a client, typically using the HTTP protocol when initiated from a computer, where the user may begin playback of the media before the download is complete. Regular streaming media and progressive download may differ in how the digital media data is received and stored by the end user device that is accessing the digital media. A media player that is capable of progressive download playback relies on meta-data located in the header of the file to be intact and a local buffer of the digital media file as it is downloaded from a web server, and at the point in which a specified amount of data becomes available to the local playback device, the media will begin to play. This specified amount of buffer is embedded into the file by the producer of the content in the encoder settings and is reinforced by additional buffer settings imposed by the media player.
Using progressive download, the end user experience is similar to streaming media, however the digital file is typically downloaded and stored in a physical drive on the end user device, typically in the temp folder of the associated web browser (if the digital media was embedded into a web page), or is diverted to a storage directory that is set in the preferences of the media player used for playback. The digital media file stutters or stops playback if the rate of playback exceeds the rate at which the file is downloaded, and the file will begin to play again after further download.
This fast start playback is the result of moving the meta data from the end of the digital media file to the front, this move of the meta-data gave the media player all the information it required to begin playback as the file was still being downloaded. Prior to that change, the meta data summary was located at the end of a digital media file and the entire file would need to be downloaded in order for the meta data to be read and the player begin playback. Initially, the file is played from the beginning. For Flash video seeking requires a list of seek points in the media file metadata, where these points are offsets in the video (both in seconds and bytes) at which a new key frame starts. A web server or a media server that handles the download, must support seek points in query string of requests for downloading data. For other types of media files such as MP4 or MKV, web servers must be capable of handling a special offset parameter, which name differs for various servers and is specified in the player settings.
Adaptive BitRate (ABR) streaming. Adaptive bitrate (ABR) streaming is a technique used in streaming multimedia over computer networks typically based on HTTP and designed to work efficiently over large distributed HTTP networks such as the Internet. It works by detecting a user bandwidth and CPU capacity in real time and adjusting the quality of a video stream accordingly. It requires the use of an encoder that can encode a single source video at multiple bit rates. The player client switches between streaming the different encodings depending on available resources. Typically, adaptive bitrate streaming is a method of video streaming over HTTP where the source content is encoded at multiple bit rates, then each of the different bit rate streams are segmented into small multi-second parts. The streaming client is made aware of the available streams at differing bit rates, and segments of the streams by a manifest file. When starting, the client requests the segments from the lowest bit rate stream. If the client finds the download speed is greater than the bit rate of the segment downloaded, then it will request the next higher bit rate segments. Later, if the client finds the download speed for a segment is lower than the bit rate for the segment, and therefore the network throughput has deteriorated, then it will request a lower bit rate segment. The segment size can vary depending on the particular implementation, but they are typically between one (1) and ten (10) seconds. While adaptive bitrate technology requires additional encoding, but simplifies the overall workflow and creates better results. Adaptive bitrate streaming over HTTP is described in an article by Saamer Akhshabi et al. presented MMsys' 11 (dated Feb. 23-25, 2011) [ACM 978-1-4503-0517-4/11/02] entitled: “An Experimental Evaluation of rate-Adaptation algorithms in Adaptive Streaming over HTTP”, and in an article published by Rivier University in ‘InSight: Rivier Academic Journal, Volume 9, Number 2, Fall 2013’ [ISSN 1559-9388] by Ted. D. Monchamp entitled: “Adaptive Bit-Rate Streaming—Minimizing End-User Buffer Times in Real-Time Video Delivery”, which are both incorporated in their entirety for all purposes as if fully set forth herein.
DASH. Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH, is an adaptive bitrate streaming technique that enables high quality streaming of media content over the Internet delivered from conventional HTTP web servers. MPEG-DASH works by breaking the content into a sequence of small HTTP-based file segments, each segment containing a short interval of playback time of content that is potentially many hours in duration, such as a movie or the live broadcast of a sports event. The content is made available at a variety of different bit rates, i.e., alternative segments encoded at different bit rates covering aligned short intervals of play back time are made available. While the content is being played back by an MPEG-DASH client, the client automatically selects from the alternatives the next segment to download and play back based on current network conditions. The client selects the segment with the highest bit rate possible that can be downloaded in time for play back without causing stalls or re-buffering events in the playback. Thus, an MPEG-DASH client can seamlessly adapt to changing network conditions, and provide high quality play back with fewer stalls or re-buffering events. MPEG-DASH is standardized as an international standard ISO/IEC 23009-1:2012 entitled: “Information technology—Dynamic adaptive streaming over HTTP (DASH)—Part 1: Media presentation description and segment formats”. 
DASH is an adaptive bitrate streaming technology where a multimedia file is partitioned into one or more segments and delivered to a client using HTTP. A media presentation description (MPD) describes segment information (timing, URL, media characteristics like video resolution and bit rates), and can be organized in different ways such as SegmentList, SegmentTemplate, SegmentBase and SegmentTimeline, depending on the use case. Segments can contain any media data, however the specification provides specific guidance and formats for use with two types of containers: ISO base media file format (e.g. MP4 file format) or MPEG-2 Transport Stream. DASH is audio/video codec agnostic. One or more representations (i.e., versions at different resolutions or bit rates) of multimedia files are typically available, and selection can be made based on network conditions, device capabilities and user preferences, enabling adaptive bitrate streaming and QoE (Quality of Experience) fairness. DASH is also agnostic to the underlying application layer protocol.
DASH is described in an article by C. Müller and C. Timmerer published in Proceedings of the ACM Multimedia 2011 presented MM'11 (Nov. 28-Dec. 1, 2011) [ACM 978-1-4503-0616-4/11/11] entitled: “A VLC Media Player Plugin enabling Dynamic Adaptive Streaming over HTTP”, in an article by S. Lederer, C. Mueller and C. Timmerer, presented in Proceedings of the ACM Multimedia Systems Conference 2012 (MMSys' 12, Feb. 22-24, 2012) [ACM 978-1-4503-1131-1/12/02] entitled: “Dynamic Adaptive Streaming over HTTP Dataset”, in an IEEE Computer Society article published 2011 by Iraj Sodagar entitled: “The MPEG-DASH Standard for Multimedia Streaming Over the Internet”, in a paper published November 2011 by RGB Networks entitled: “Comparing Adaptive HTTP Streaming Technologies”, in an article by Christopher Müller, Stefan Lederer and Christian Timmerer presented MoVid'12, Feb. 24, 2012 [ACM 978-1-4503-1166-3/12/02] entitled: “An Evaluation of Dynamic Adaptive Streaming over HTTP in Vehicular Environments”, and in ETSI technical specification ETSI TS 126 247 V13.2.0 (2016-01) entitled: “Universal Mobile Telecommunications System (UMTS); LTE; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (3GPP TS 26.247 version 13.2.0 Release 13)”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
HLS. HTTP Live Streaming (HLS) is an HTTP-based media streaming communications protocol implemented by Apple Inc. as part of its QuickTime, Safari, OS X, and iOS software. It works by breaking the overall stream into a sequence of small HTTP-based file downloads, each download loading one short chunk of an overall potentially unbounded transport stream. As the stream is played, the client may select from a number of different alternate streams containing the same material encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate. At the start of the streaming session, it downloads an extended M3U playlist containing the metadata for the various sub-streams which are available. Since its requests use only standard HTTP transactions, HTTP Live Streaming is capable of traversing any firewall or proxy server that lets through standard HTTP traffic, unlike UDP-based protocols such as RTP. This also allows content to be offered from conventional HTTP servers as origin and delivered over widely available HTTP-based content delivery networks. HLS also specifies a standard encryption mechanism using AES and a method of secure key distribution using HTTPS with either a device specific realm login or HTTP cookie which together provide a simple DRM system. Later versions of the protocol also provide for trick mode fast-forward and rewind and integration of subtitles. upLynk has also added the AES scrambling and base-64 encoding of the DRM content key with a 128-bit device specific key for registered commercial SWF applications together with a sequential initialization Vector for each chunk to its implementation of the standard.
HTTP Live Streaming uses a conventional web server to distribute audiovisual content and requires specific software to fit into the proper format transmission in real time. In HLS, the server codify and encapsulate the input video flow in a proper format for the delivery. Then, it is prepared for distribution by segmenting it into different files. In the process of intake, the video is coded and segmented to generate video fragments and index file. An encoder codifies video files in H.264 format and audio in MP3, HE-AAC or AC-3, later encapsulated by MPEG-2 Transport Stream to carry it. A segmenter divides the MPEG-2 TS file into fragments of equal length, kept as .ts files, and also creates an index file that contains references of the fragmented files, saved as .m3u8. A distributor, formed by standard web Server, accepts requests from clients and delivery all the resources needed for streaming. The client requests and downloads all the files and resources, assembling them so that they can be presented to the user as a continuous flow video. The client software downloads first the index file through a URL and then the several media files available. The playback software assembles the sequence to allow continued display to the user. HTTP Live Streaming provides mechanisms to provide a scalable and adaptable to network, allowing playback quality in wireless networks with high bandwidth and low quality playback on 3G networks, where the bandwidth is reduced. HTTP Live Streaming also provides protection against errors, generating alternative different flows video to use them if there are any errors in segment.
To make the system scalable and adaptable to the bandwidth of the network, the video flow is coded in different qualities. Thus, depending on the bandwidth and transfer network speed, the video will play at different qualities. To implement this, the system must encode the video in different qualities and generate an index file that contains the locations of the different quality levels. The client software internally manages the different qualities, making requests to the highest possible quality within the bandwidth of the network. Thus always play the video the highest possible quality, viewing lower quality on 3G networks and highest quality in Wi-Fi broadband. To keep a stream available HLS includes features to recover from outages, so multiple flows are listed in the index file for the same quality level. If the client can't load a flow it tries the next, repeating until either a working flow is found or all flows fail. This can be combined with scalability by listing multiple flows for each separate quality.
HLS is described in IETF Informational Internet-Draft published Apr. 16, 2014 by R. P. Pantos entitled: “HTTP Live Streaming-draft-pantos-http-live-streaming-13”, in a paper published January 2010 by Andrew Fecheyr-Lippens entitled: “A Review of HTTP Live Streaming”, in Apple Inc. Technical Note TN2224 updated 2015 May 4 entitled: “Best Practices for Creating and Deploying HTTP Live Streaming Media for the iPhone and iPad”, and in a paper by Hongfeng Xu, Then Chen, Rui Chen, and Junwei Cao from Tsinghua University, Beijing, China (downloaded 3-2016) entitled: “Live Streaming with Content Centric Networking”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
HDS. Adobe HTTP Dynamic Streaming (HDS) is the process of efficiently delivering streaming video to users by dynamically switching among different streams of varying quality and size during playback. This provides users with the best possible viewing experience their bandwidth and local computer hardware (CPU) can support. Another major goal of dynamic streaming is to make this process smooth and seamless to users, so that if up-scaling or down-scaling the quality of the stream is necessary, it is a smooth and nearly unnoticeable switch without disrupting the continuous playback. HDS is described in Adobe Systems Incorporated 2013 published specifications entitled: “HTTP Dynamic Streaming Specification—Version 3.0 FINAL”, in an Adobe Flash Platform Technical White Paper published 2010 entitled: “HTTP Dynamic Streaming on the Adobe® Flash® Platform—Enabling high-quality, network-efficient HTTP streaming for media delivery” [Document 91030544 9/10], and in Adobe Systems Incorporated 2010 user guide entitled: “Using Adobe® HTTP Dynamic Streaming”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
Buffer. A buffer (or ‘data buffer’) is a region of a physical memory storage used to temporarily store data, typically while it is being moved from one place to another. Typically, the data is stored in a buffer as it is retrieved from an input device, or just before it is sent to an output device; however, a buffer may be used for moving data between processes within a computer. The data stored in a data buffer is commonly stored on a physical storage medium (volatile or non-volatile memory), such as the main memory 15a or the storage device 15c, and may be implemented as buffer mechanism in software using a fixed memory location in hardware, or by using a virtual data buffer in software, pointing to a location in the physical memory. Buffers are used when there is a difference between the rate at which data is received, and the rate at which it can be processed, or in the case that these rates are variable, for example, in a printer spooler or in online video streaming. Buffers normally use an FIFO (First In, First Out) scheme, outputting data in the order it arrived. A buffer may further be used for adjusting timing by implementing a queue (or FIFO) algorithm in a memory, simultaneously writing data into the queue at one rate, and reading it at another rate.
An example of buffer operation in content streaming context is shown as a graph 80 in FIG. 8. A horizontal axis ‘t’ 82 represents the passing time, while a vertical axis 81 ‘Mbits’ represents the amount of content received or consumed/processed. A diagonal line 84 represents the rate of the media player consuming data from the buffer, allowing de-compression (in case of compressed data, such as MPEG-4), preparing for presentation, and displaying the content on a display (such as the display 17) to a user. The buffer receiving operation, such as from an external server over the Internet, is shown as a ‘staircase’ line 83. The streaming process starts at time point t=0, which may correspond to a “Content Request” step 61 in the flow-chart 60 as shown in FIG. 6. After the overhead associated with a “Request Routing” step 62, an “Identify Replica Server” step 63, and a “Streaming Request” step 64, the streaming starts as part of a “Content Streaming” step 65, the buffer starts loading the content data at a time point t1 86a. The buffer starts receiving and loading content data, as shown by a slope line 83a, and upon reaching a pre-set threshold L1 81a (which may correspond to user content displaying time, such as 5 or 10 seconds) at a time point t2 86b, the media player starts consuming data from the buffer and presenting it to the user at a rate corresponding to the slope of the line 84. The time interval t2 86b is known as ‘start-up’ time, and reducing this time allows for better user experience due to the shorter waiting time for the content playing start.
After the time point t2 86b and during a time interval t2-t3 82a, the buffer continues to receive and load content in parallel with the media player consuming content from the buffer, until the buffer reaches a maximum level or a maximum defined capacity L2 81b at a time point t3 86c. At this time point t3 86c, the receiving process is stopped as represented by a horizontal line 83b, in order to avoid buffer overflow, while the media player continues to consume content from the buffer. After a time interval t3-t4 82b, at a time point t4 86d, the buffer content level reaches a minimum pre-set threshold, and thus starts again to receive and store content from the content source as shown by a slope line 83c, until a time point t5 86e (during a t4-t5 time interval 82c). The process is repeated until the buffer reaches a maximum level or a maximum defined capacity where the total received content level is L3 81c, at a time point t5 86e. At this time point t5 86e, the receiving process is stopped as represented by a horizontal line 83d, in order to avoid buffer overflow, while the media player continues to consume content from the buffer. After a time interval t5-t6 82d, at a time point t6 86f, the buffer content level again reaches a minimum pre-set threshold, and thus starts again to receive and store content from the content source as shown by a slope line 83e, until time point t7 86g (during a t6-t7 time interval 82e), where the total content received level is L4 81d. Again, at this time point t7 86g, the receiving process is stopped as represented by a horizontal line 83f, in order to avoid buffer overflow, while the media player continue to consume content from the buffer. After a time interval t7-t8 82f, at a time point t8 86h, the buffer content level again reaches a minimum pre-set threshold, and thus starts again to receive and store content from the content source as shown by a slope line 83g, until time point t9 86i (during a t8-t9 time interval 82g), where the total content received level is L5 81e. At this time point t9 86i, the receiving process is stopped as represented by a horizontal line 83h, in order to avoid buffer overflow, while the media player continue to consume content from the buffer, until a time point t10 86j, during a time interval t9-t10 82h. 
The quantity of data in the buffer is repeatedly growing or falling, according to the system states, shown as a dashed line 85. When no content is received, such as in the t5-t6 time interval 82d, the buffer is being emptied by the media player, thus the content level is reduced (negative slope 85a) at the rate of the media player data consumption, until reaching a minimum level 116a. However, when the content is received, such as in the t6-t7 time interval 82e, the net content rate (the received rate minus the media player consuming rate) in the buffer increases (positive slope 85b) at the rate of the media player data consumption, until reaching a maximum level 116b. 
The playing rate (designated as PLAYER_RATE), which is the average rate the media player consumes the data from the buffer, represented as the slope of line 84 in the graph 80, may be calculated by PLATER_RATE=(L3−L2)/(t6−t4) or by PLAYER_RATE=(L4−L3)/(t8−t6), and is typically constant throughout the content playing. Similarly, the content receiving rate (designated as RECEIVING_RATE), represented as the slope of the line 83 in the graph 80 when data is received and loaded into the buffer, may be calculated to be RECEIVING_RATE=L2/(t3−t1) at the t2-t3 time interval 82a (represented as the slope of the line 83a in the graph 80), and RECEIVING_RATE=(L3−L2)/(t5−t4) at the t5-t4 time interval 82c (represented as the slope of the line 83c in the graph 80). The receiving rate may change over time due to various changes in the content providing server, communication problems, and other changes in the system providing the content from the server to the client device. The total content size of the content to be played may be designated as CONTENT_SIZE, thus the playing time may be calculated to be CONTENT_SIZE/PLAYER_RATE. A playing time of T seconds requires a content of T*PLAYER_RATE.
In one example, the content to be received and played is a video content, such as a movie. The size of the movie content (CONTENT_SIZE) may be 900 MB (MB=MegaBytes) (=0.9 GB-GigaBytes), and the PLAYER_RATE may be 200 KB/s (200 KiloBytes per second, =1.6 Mb/s-MegaBits per second), resulting a total playing time of 4,500 second (75 Minutes). In a case where the buffer is designed to store 10 seconds of playing time, the buffer minimum storage size should be 2000 KB (2 MB-MegaBytes). Similarly, buffering a playing time of 20 seconds requires a storage of 4000 KB (4 MB), and 30 seconds playing time requires 6000 KB (6 MB).
In order to allow for minimum start-up time and guaranteeing continuous operation, the receiving rate (RECEIVING_RATE) should be at least equal to the PLAYER_RATE. Preferably and practically, in order to allow efficient buffering to overcome various fluctuations in the system operations such as variations in the receiving rate, the receiving rate should be substantially higher than the playing rate, such as at least 50% above the playing rate (RECEIVING_RATE>1.5*PLAYER_RATE), or twice the playing rate (RECEIVING_RATE>2*PLAYER_RATE). Hence, in the above example, the RECEIVING_RATE should be at least 300 KB/s (1.5*200 KB/s=2.4 Mb/s), or preferably above 400 KB/s (2*200 KB/s=3.2 Mb/s).
VOD. Video-On-Demand (VOD) or Audio and Video On Demand (AVOD) are systems that allow users to select and watch/listen to video or audio content any time, rather than having to watch at a specific broadcast time. For example, IPTV technology is often used to bring video on demand to televisions and personal computers.
Television VOD systems can either stream content through a set-top box, a computer, or other device, allowing viewing in real time, or download it to a device such as a computer, digital video recorder (also called a personal video recorder), or portable media player for viewing at any time. The majority of cable- and telco-based television providers offer both VOD streaming, including pay-per-view and free content, whereby a user buys or selects a movie or television program and it begins to play on the television set almost instantaneously, or downloading to a DVR rented from the provider, or downloaded onto a PC, for viewing in the future.
Other forms of video on demand include “Subscription Video On Demand” (SVOD), which includes services such as Netflix that require users to pay a monthly fee to access a bundled set of content. Another subset of video on demand is “Advertising Video On Demand” (another kind of AVOD), which includes services such as Hulu or Sony's Crackle. This AVOD is often free for users, and the platforms rely on selling advertisements as a main revenue stream.
Downloading and streaming video on demand systems provide the user with a large subset of VCR functionality including pause, fast forward, fast rewind, slow forward, slow rewind, jump to previous/future frame, etc. Interactive Video On Demand (IVOD) is a common version of video on demand where people have the following features at their disposal: Play/Resume-Start a program/movie from the beginning or resume after temporarily stopping the show; Stop-Temporarily or permanently stop the presentation of the show; Pause-Freeze the picture; Jump forward-Jump to a particular time in the presentation (movie) in a forward direction; Jump backward-Jump to a particular time in the presentation (movie) in a backward direction; Fast Forward (FF)—Browse through the movie in the forward direction with picture and sound on; Slow Down—Going forward at a lower rate than normal but with picture and sound; Reverse—Playing the movie in the reversed direction with picture and sound; Fast Reverse—Browse the presentation in the backward direction with picture and sound at a faster speed than standard reverse; and Slow Reverse: Go backward at a slower speed, with picture and sound. Other interactive features include the ability to avoid or select advertisements, to investigate additional details about news events and to browse, select, and purchase goods.
Two common major types of VOD are streaming video and non-streaming video. Streaming video (sometimes known as HTTP Streaming video or Progressive Download) is when the video is compressed and sent over a network, such as the Internet, and then decompressed by the receiver (such as set-top box) for displaying on your screen. Typically, the file begins displaying before it has completely been delivered to the set-top box (to save transmission time and bandwidth). The non-streaming variety of video needs the downloaded files to be completely sent before they can be played.
An arrangement 40 for providing a VOD streaming service is shown in FIG. 4. A VOD Service provider employs a network or system 49, typically including a VOD Service Server 48 for handling the customer access, authorization, billing, and general management, which is connected (or part of) to an Origin Server 41, which stores (or communicates with) a content to be streamed in a memory 46, such as a movie #1 47a and a movie #2 47b. The VOD service provider system 49 is communicating with the client #1 device 24 via the Internet 22. The client #1 24 sends to the VOD service server 48 (shown as dashed line 44a) a request for a content, such as for the movie #1 47a, and upon approval by the VOD provider, the requested content is streamed from the VOD service server 48 (or the origin server 41) to the client #1 24 (shown as dashed line 44b).
CDN. A Content Delivery Network or Content Distribution Network (CDN) is a large distributed system of servers deployed in multiple data centers across the Internet, deployed in order to serve content to end-users with high availability and high performance. CDNs serve a large fraction of the Internet content today, including web objects (text, graphics and scripts), downloadable objects (media files, software, and documents), applications (e-commerce, portals), live streaming media, on-demand streaming media, and social networks. Content providers such as media companies and e-commerce vendors pay CDN operators to deliver their content to their audience of end-users. In turn, a CDN pays ISPs, carriers, and network operators for hosting its servers in their data centers.
Besides better performance and availability, CDNs also offload the traffic served directly from the content provider's origin infrastructure, resulting in possible cost savings for the content provider. In addition, CDNs provide the content provider a degree of protection from DoS attacks by using their large distributed server infrastructure to absorb the attack traffic. Most CDNs are operated as an Application Service Provider (ASP) on the Internet (also known as on-demand-software or software-as-a-service). An increasing number of Internet network owners have built their own CDNs to improve on-net content delivery, reduce demand on their own telecommunications infrastructure, and generate revenues from content customers, such as by offering access to media streaming to Internet service subscribers. An example of a CDN is the Akamai Network, operated by Akamai Technologies headquartered in Cambridge, Ma, U.S.A., and described in an article entitled: “The Akamai Network: A Platform for High-Performance Internet Applications” by Erik Nygren, Tamesh K. Sitaraman, and Jennifer Sun, which is incorporated in its entirety for all purposes as if fully set forth herein. CDN technologies and concepts are further described in an article published by Grid Computing and Distributed System (GRIDS) Laboratory of the University of Melbourne, Australia, authored by Al-Mukaddim Khan Pathan and Rajkumar Buyya entitled: “A Taxonomy and Survey of Content Delivery Networks”, and in an article by Vijay Kumar Adhikari and Zhi-Li Zhang of the University of Minnesota, and Yang Guo, Fang Hao, Matteo Varvello, Volker Hilt, and Moritz Steiner of Bell-Labs/Alcatel-Lucent, entitled: “Unreeling Netflix: Understanding and Improving Multi-CDN Movie Delivery”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
In one CDN scheme, the content (potentially multiple copies) may exist on several servers, and when a user makes a request to a CDN hostname, DNS will resolve to an optimized server (based on location, availability, cost, and other metrics) and that server will handle the request. CDN nodes are typically deployed in multiple locations, often over multiple backbones, thus allowing benefits such as reducing bandwidth costs, improving page load times, or increasing global availability of content. The number of nodes and servers making up a CDN varies, depending on the architecture, some reaching thousands of nodes with tens of thousands of servers on many remote Points of Presence (PoPs), while others build a global network and have a small number of geographical PoPs.
Most CDN providers will provide their services over a varying, defined, set of PoPs, depending on the geographic coverage desired, such as the United States, International or Global, or Asia-Pacific. These sets of PoPs are referred to as “edges” or “edge networks” as they are the closest edge of CDN assets to the end user. The CDN's Edge Network grows outward from the origin(s) through further acquisitions (via purchase, peering, or exchange) of co-locations facilities, bandwidth, and servers. Content Delivery Networks augment the end-to-end transport network by distributing on it a variety of intelligent applications employing techniques designed to optimize content delivery. The resulting tightly-integrated overlay uses web caching, server-load balancing, request routing, and content services. CDNs use a variety of methods of content delivery including, but not limited to, manual asset copying, active web caches, and global hardware load balancers. Several protocol suites are designed to provide access to a wide variety of content services distributed throughout a content network. The Internet Content Adaptation Protocol (ICAP) and the Open Pluggable Edge Services (OPES) protocols are open standards for connecting application servers.
A CDN typically employs multiple replicas, or point of presence of content, in different locations that are geographically far apart from the origin server and from each other, but closer to the clients. A CDN directs the client's request to a good replica, which in turn serves the items on behalf of the origin server. A good replica means that the item is served to the client quickly, compared to the time it would take to serve the same item from the origin server, with essential quality, integrity, and consistency. A network service provider can build and operate a CDN to offer content distribution service to a number of content providers. This helps content providers to outsource the network infrastructure, and to focus their resources on developing high-value content, not on managing the network. For example, Akamai, Sandpipper/Digital Island, and Adero are content distribution service providers that provide content publishers such as CNN, Disney, AOL, Viacom, and content aggregators such as Broadcast.com and Spinner, with the means to deliver content distribution and delivery.
A CDN maintains a large number of replicas or surrogate servers in proximity to the end users, to act on behalf of the origin severs owned by different content providers. The CDN removes the delivery of content from a centralized site to multiple and highly distributed sites, and overcomes the issues of network size, congestion, and failures, and establishes business relationships with the content providers to act on behalf of them. A typical CDN consists of several surrogate servers, a distribution system, a request-routing system, and an accounting system. An example of a CDN 49 is shown as part of arrangement 40a in FIG. 4a. A CDN #1 45a is shown, including a CDN manager server 43 that manages the CDN #1 45a, and three exemplary replica servers, designated as a Replica Server #1 42a, Replica Server #2 42b, and Replica Server #3 42c. The replica servers 42a, 42b, and 42c include, or are connected to, a respective storage 46a, 46b, and 46c, each of the storages include copies of the movie #1 47a and movie #2 47b, being copies of the original content stored in the origin server 41 memory 46.
A replica/surrogate server receives a mapped request, and delivers the corresponding content to the client. The CDN consists of a collection of network elements called content-distributor, to support the activity of moving a publisher's content from the origin server to one or more surrogate servers. Distribution can happen when a surrogate server either anticipates or receives a client request (‘push’), or in response to a surrogate server receiving a client request (‘pull’). The CDN also propagates content signals that specify information, such as validation and expiration about the content, and uses these content signals to maintain the integrity and consistency of the content in its surrogate servers. The Distribution system interacts with the request-routing system to inform the content availability in different surrogate servers. It also interacts with the accounting system to inform the content distribution activity so that the later can measure the volume of content distribution.
Request-Routing. Requests for content are typically algorithmically directed to nodes that are optimal in some way. When optimizing for performance, locations that are best for serving content to the user, may be chosen. This may be measured by choosing locations that are the fewest hops, the least number of network seconds away from the requesting client, or the highest availability in terms of server performance (both current and historical), so as to optimize delivery across local networks. When optimizing for cost, locations that are least expensive, may be chosen instead. In an optimal scenario, these two goals tend to align, as servers that are close to the end-user at the edge of the network may have an advantage in performance or cost.
Request routing directs client requests to the content source best able to serve the request. This may involve directing a client request to the service node that is closest to the client, or to the one with the most capacity. A variety of algorithms are used to route the request, such as Global Server Load Balancing, DNS-based request-routing, Dynamic metafile generation, HTML rewriting/redirecting, and anycasting. Proximity—choosing the closest service node, is estimated using a variety of techniques, including reactive probing, proactive probing, and connection monitoring.
A request-routing system enables the activity of directing a client request to a suitable surrogate server. It consists of a set of network elements called request routers that work in cooperation to direct a request. They also use dynamic information about network conditions and load on the surrogate servers to balance the load while directing requests. The Request-routing system interacts with the accounting system to inform the content delivery to the clients, and interacts with the distribution system to inform the demand of content.
In general, Request-Routing techniques may be classified under DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing, as described in IETF RFC 3568 entitled: “Known Content Network (CN) Request-Routing Mechanisms”, which is incorporated in its entirety for all purposes as if fully set forth herein. Various request routing techniques are described in an article by Varum Khare and Beichuan Zhang of the University of Arizona entitled: “CDN Request Routing to Reduce Network Access Cost”, in an article by Md. Humayun Kabir, Eric G. Manning, and Gholamali C. Shoja of the University of Victoria, Canada, entitled: “Request-Routing Trends and Techniques in Content Distribution Network”, in a paper published in the International Journal of Computer Applications (0975-8887) Col. 76-No. 13, August 2013 authored by Erwin Harahap, Janaka Wijekoon, Rajitha Tennekoon, and Fumito Yamaguchi of Keio University, Japan, entitled: “Modeling of Routing-based Request Redirection for Content Distribution Network”, and in a paper published June 2001 by SinoCDN Limited entitled: “Request Routing, Load-Balancing and Fault-Tolerance Solution—MediaDNS”, which are all incorporated in their entirety for all purposes as if fully set forth herein. An example of a Request-Routing technique is described in a U.S. Pat. No. 8,577,992 to Richardson et al. entitled: “Request Routing Management Based on Network Components”, which is incorporated in its entirety for all purposes as if fully set forth herein.
The system operation is described in a flow chart 60 in FIG. 6, corresponding to the exemplary arrangement 50 shown in FIG. 5. In the “Content Request” step 61, corresponding to dashed-line message 51a in FIG. 5, the client device #1 24 send a request to the VOD service server 48 for a specific video content, such as the movie #1 47a. The VOD service provider 49 uses the CDN #1 45a for the actual content delivery, and thus after appropriate authentication and billing procedures, the VOD service provider 49 ask the CDN provider, such as via a request to CDN manager 43 to forward the requested content to the client device #1 24. A request-routing scheme is performed as part of the “Request Routing” step 62, where the optimal replica server is selected according to pre-set criteria, for example selecting the replica server #1 42a. The optimal replica server is identified and the client device #1 24 is notified in the “Identify Replica Server” step 63. For example, the client device #1 24 may be notified by the VOD service server 48, as illustrated by a message 51b in FIG. 5. The client device #1 24 then sends the content request to the identified optimal replica server #1 42a as part of the “Streaming Request” step 64, corresponding to a message 51c in FIG. 5. The request is followed by the replica server #1 42a starting to stream the requested content to the client device #1 24 as part of the “Content Streaming” step 65, corresponding to the dashed line 51d shown in FIG. 5. Once the optimal replica server (such as the replica server #1 42a) is selected as part of the request routing algorithm in the “Request Routing” step 62 and identified by the client device #1 24 as part of the “Identify Replica Server” step 63, the content is continuously streamed in full from the selected replica server (the replica server #1 42a) to the client device #1 24, until the whole content has been streamed (e.g., the selected movie #1 47a is streamed in full until completed).
A popular request-routing method is known as ‘HTTP-Redirect’ and is based on using an HTTP response status code ‘302 Found’ for performing URL redirection. An HTTP response with this status code additionally provides a URL in the Location header field, and the user agent (e.g. a web browser) is invited by a response with this code to make a second, otherwise identical, request to the new URL specified in the Location field. The HTTP/1.0 specification (RFC 1945) initially defined this code, and gives it the description phrase “Moved Temporarily”.
An HTTP-Redirect based arrangement 70 is shown in FIG. 7. Similar to message 51a above, the process starts with the “Content Request” step 61 where a content request is sent, shown as dashed line 71a, from the client device #1 24 to the VOD service provider 49. The response from the VOD service server 48 comprises an identification of the CDN #1 45a manager server 43. The client device #1 24 then directs its request for content to the CDN manager 43, shown as message 71c. The CDN manager server 43 uses the HTTP ‘302 Found’ mechanism to notify the client device #1 24 (shown as dashed line 71d) that the request should be redirected to the Replica Server #1 42a, identified as the replica server to be used as part of the “Identify Replica Server” step 63. The request is then redirected by the client device #1 24 to the identified replica server #1 42a (message 71e), and the streaming process starts (dashed line 71f) from the replica server #1 42a to the client device #1 24. Typically, the same identified replica server, such as the replica server #1 42a in this example), is used throughout the total streaming of the content until whole of the requested content is received at the client device #1 24.
Another commonly used request-routing method referred herein is ‘CDN-Redirect’, and is based on the CDN Manager Server 43 providing the identification of the replica server to the VOD Service server 48, which in turn, provides it to the client #1 device 24. Such a ‘CDN-Redirect’ based arrangement 70a is shown in FIG. 7a. Similar to message 51a above, the process starts with the “Content Request” step 61 where a content request is sent, shown as dashed line 71a, from the client device #1 24 to the VOD service provider 49. Upon receiving the content request, the VOD Service Server 48 decides to use CDN #1 45a, and sends a request for replica server to the CDN Manager server 43, shown as dashed line 72a. The CDN Manager server 43 then select an appropriate replica server (according to availability and pre-set criteria), and sends the selected replica server identification (Replica Server #1 42a in this example) back to the VOD Service Server 48 (dashed line 72b). Then the identification of the selected replica server is sent to the content requesting client #1 device 24 (dashed line 72c). The request is then redirected by the client device #1 24 to the identified replica server #1 42a (message 71e), then the streaming process starts (dashed line 71f) from the replica server #1 42a to the client device #1 24.
Another commonly used request-routing method is referred herein as ‘DNS-Based’ or ‘DNS-Redirect’, and is based on the DNS scheme for resolving the identity of the selected replica server. Such a ‘DNS-Redirect’ based arrangement 70b is shown in FIG. 7b. Similar to message 51a above, the process starts with the “Content Request” step 61 where a content request is sent, shown as a dashed line 71a, from the client device #1 24 to the VOD service provider 49. Upon receiving the content request, the VOD Service Server 48 sends a domain name (rather than IP address or any other server identification), shown as dashed line 71b. As part of a normal DNS scheme, the requested domain name is sent to a DNS server 74 (may be part of the ISP 26 or communicating with it), shown as dashed line 73d. The DNS resolution scheme involves the DNS server 74 communicating with a domain-name directed DNS server, which may be the CDN Manager Server 43 shown as dashed line 73c, which in turn returns the identification (typically IP address) of the selected replica server (such as the replica server #1 42a as part of CDN #1 45a). The resolved IP address is then returned by the DNS server 74 to the client #1 device 24 (shown as a dashed line 73a) followed by a standard streaming process as described herein.
The states, and messages associated with using the HTTP-Redirect Request-Routing scheme, shown as the arrangement 70 in FIG. 7, are further described in a timing, states, and messaging chart 90 shown in FIG. 9. The chart 90 shows the messaging and related timing associated with the operation of the client #1 device 24 (corresponding to a dashed line 92a), the VOD Service server 48 (corresponding to a dashed line 92b), the CDN #1 45a Manager Server 43 (corresponding to a dashed line 92c), and the resolved Replica Server #1 42a (corresponding to a dashed line 92d). The requested content is identified in the client #1 device 24 in the ‘Start’ state 93a, and the request for the content is sent as a ‘Content Request’ message 94a to the VOD Service Server 48 (corresponding to the “Content Request” step 61 in the flow-chart 60, and to the dashed line 71a in the arrangement 70). The VOD service provider 49 selects CDN #1 as the medium for content delivery in a ‘Select CDN #1’ state 93b, and send back the CDN #1 45a Manager Server 43 identification to the client #1 device 24 as a ‘Send Manager’ message 94b (corresponding to the dashed line 71b in the arrangement 70). After receiving the message 94b at a ‘Send to CDN #1’ state 93c, the client #1 device 24 sends a ‘Content Request’ message 94c (corresponding to the dashed line 71c in the arrangement 70) to the CDN Manager Server 43. After selecting the replica device to use, a ‘HTTP-Redirect’ state 93d is used to notify the client #1 device 24 of the identification of the selected replica server using a ‘Notify Replica’ message 94d (corresponding to the dashed line 71d in the arrangement 70). The steps starting at the ‘Content Request’ message 94a until the client #1 device 24 is notified of the Replica Server to use (in this example the replica server #1 42a), are part of the Request-Routing scheme, corresponding to the “Request Routing” step 63 of the flow chart 60. Once the replica server to be used in identified by the client #1 device 24 (corresponding to the “Identify Replica Server” step 63 in the flow chart 60), a ‘Content Request’ message 94e is sent to the selected replica server #1 42a (corresponding to the “Streaming Request” step 64 in the flow chart 60 and to the dashed line 71e in the arrangement 70), which in turn prepares the requested content in a ‘Prepare Content’ state 93e, followed by streaming the content to the requesting client #1 device 24 as a ‘Content Streaming’ message 94f (corresponding to the “Content Streaming” step 65 in the flow chart 60 and to the dashed line 71f in the arrangement 70). While the states and messaging chart 90 described an HTTP-Redirect scheme, any other Request-Routing scheme may be equally employed.
A timing, states, and messaging chart 90 shown in FIG. 9 schematically describes the activities of the various entities shown in arrangement 70 in FIG. 7 and described in flow chart 60 in FIG. 6. The entities involved are a client device, such as the client device #1 24 (associated with a vertical dashed line 92a), a VOD service server, such as the VOD Service Server 48 (associated with a vertical dashed line 92b), a CDN #1 manager server, such as the CDN Manager Server 43 (associated with a vertical dashed line 92c), and a selected CDN #1 replica server, such as the replica server #1 42a (associated with a vertical dashed line 92d). The process starts at a “Start” state 83a with the client device #1 24 determining that a content is required, such as a content selected to be played by the user. The client device #1 24 then send a “Content Request” message 94a to the VOD service server 48 (corresponding to the request 71a in the arrangement 70 and to the “Content Request” step 61 in the flow chart 60). Upon receiving the request, the VOD service server 48 selects a CDN to be used to deliver the requested content as part of a “Select CDN #1” state 93b, and replies with the identification of the appropriate CDN manager identification as part of a “Send Manager” message 94b (corresponding to the reply 71b in the arrangement 70). At a “send to CDN #1” state 93c the client device #1 24 receives the server identification, and sends a new “Content Request” message 94c to the identified CDN manager server 43 (corresponding to the request 71c in the arrangement 70). Using the HTTP-Redirect mechanism in a “HTTP Redirect” state 93d, the CDN Manager server 43 returns to the client device #1 24 a “Notify Replica” message 94d, identifying the selected replica server, such as the Replica Server #1 42a (corresponding to the reply 71d in the arrangement 70 and to the “Identify Replica Server” step 63 in the flow-chart 60). While using the HTTP-Redirect mechanism as an example, any other Request-Routing scheme may be equally used for identifying a replica server.
The client device then sends a “Content Request” message 94e to the selected replica server 42a (corresponding to the request 71e in the arrangement 70 and to the “Streaming Request” step 64 in the flow-chart 60), which in turn prepares the content to be sent as part of a “Prepare Content” state 93e, followed by providing the content to the client device #1 24 as part of a “Content Streaming” message 94f (corresponding to the reply 71f in the arrangement 70 and to the “Content Streaming” step 65 in the flow-chart 60), preferably using HTTP streaming, and using a buffering scheme as described regarding the graph 80 in FIG. 8 above.
A method and system for managing media streaming between clients on a client side of a network and stream servers on a stream server side of the network, and communications between the client-side and the stream server side requiring a network address translation (NAT), are described in U.S. Pat. No. 8,166,179 to Pickens et al., entitled: “Media Streaming Through a Network Address Translation (NAT) Device”, which is incorporated in its entirety for all purposes as if fully set forth herein. The method and system involve allowing the same stream server side IP address to be shared amongst multiple stream servers, so that the stream servers can simultaneously use the same IP address to source different media sessions. Because the stream servers can simultaneously use the same IP address to source different media sessions, a media session can be switched from one stream server to a different stream server without triggering STUN signaling, or a change in the NAT mapping.
A technique for managing the streaming of digital video content to multiple clients involves identifying an attribute of a content element that is streamed to a client and selecting a protection mechanism for the content element as a function of the attribute, and is described in U.S. Pat. No. 8,370,649 to Sherer et al., entitled: “Stream Control Failover Utilizing an Attribute-Dependent Protection Mechanism”, which is incorporated in its entirety for all purposes as if fully set forth herein. The protection mechanism enables streaming of the content element to the clients in the event of a resource failure. In an example, the identified attribute is an indication of the popularity of the content element (e.g., as measured by the number of active streams), such that the protection mechanism is selected as a function of the popularity of the content element. In an embodiment, protection mechanisms that offer a higher level of protection are selected for the more popular content elements, and protection mechanisms that offer a lower level of protection are selected for the less popular content elements.
Mechanisms and techniques that provide a system that provides stream data to a client by monitoring operation of a stream control protocol such as RTSP associated with stream data transmitted between a client and a first stream server are described in U.S. Pat. No. 7,509,390 to Raman et al., entitled: “Methods and Apparatus for Controlling the Transmission of Data”, which is incorporated in its entirety for all purposes as if fully set forth herein. The system detects a stream change event related to transmission of the stream data between the client and the first stream server, and identifies a relative position within the stream data based on the operation of the stream control protocol. The system then establishes transmission of the stream data between the client and a second stream server starting at the relative position in the stream data. The system provides for mid-stream failover for the transmission of stream data, such as real-time data with minimal perceptible loss of stream data by the client.
A client player that performs a query to a nameserver against a network map of Internet traffic conditions is described in U.S. Pat. No. 7,299,291 to Shaw entitled: “Client-Side Method for Identifying an Optimum Server”, which is incorporated in its entirety for all purposes as if fully set forth herein. The query is made, asking for a particular service (e.g., RTSP) via a particular protocol (TCP) in a particular domain. In response, the nameserver returns a set of one or more tokens, with each token defining a machine or, in the preferred embodiment, a group of machines, from which the player should seek to obtain the stream. The player may then optionally perform one or more tests to determine which of the set of servers provides the best quality of service for the stream. That server is then used to retrieve the stream. Periodically, the client player code repeats the query during stream playback to determine whether there is a better source for the stream. If a better source exists, the player performs a switch to the better stream source “on the fly” if appropriate, to maintain and/or enhance the quality of service.
A system for affecting a dynamic switch from an existing client-server connection established between a client node and a server node on a Data-Packet-Network (DPN) to an alternate server-node, connected to the network, and accessible to the client node is described in U.S. Patent Application Publication No. 2002/065922 to Shastri entitled: “Method and Apparatus for Selection and Redirection of an Existing Client-Server Connection to an Alternate Data Server Hosted on a Data Packet Network (DPN) Based on Performance Comparisons”, which is incorporated in its entirety for all purposes as if fully set forth herein. In a preferred embodiment, the system utilizes a unique software module residing on and executing from a client-node, which functions to monitor current Quality of Service (QoS) data relative to existing client-server connections. The module opens temporary client-server connections to alternate servers while a user is connected to an existing server for the purpose of sampling QoS characteristics of the alternate servers and associated network paths, and generating estimations of total value of services. The module compares actual QoS values with estimated values, and selects an alternate server based on results of the comparison. A dynamic switch of server connection may be automatically achieved, which is largely transparent to a user operating the client node.
An invention that switches a source of a streaming session between a primary server and its client, from the primary server to another server at arbitrary points during the progress of the streaming session, is described in U.S. Pat. No. 6,377,996 to Lumelsky et al., entitled: “System for Seamless Streaming of Data Stored on a Network of Distributed Primary and Target Servers Using Segmentation Information Exchanged Among All Servers During Streaming”, which is incorporated in its entirety for all purposes as if fully set forth herein. The switching of the source is accomplished by using a virtual socket capable of simultaneously phasing in a new streaming connection, while phasing out an old streaming connection during a streaming session that preserves the temporal progress of the session. The virtual socket acts as a client-based intermediary between the client and one or more streaming servers, thus enabling a client application to establish a streaming connection with respect to content and not to the end-party, i.e., server.
A client-based system for the fault-tolerant delivery of real-time or continuous data streams, such as real-time multimedia streams, e.g., live audio and video clips, is described in U.S. Pat. No. 6,195,680 to Goldszmidt et al., entitled: “Client-Based Dynamic Switching of Streaming Servers for Fault-Tolerance and Load Balancing”, which is incorporated in its entirety for all purposes as if fully set forth herein. Multimedia servers are grouped into two or more sets. For example, a first set may include one or more primary servers using odd-numbered ports and a second set may include one or more secondary servers using even-numbered ports. The client requests a multimedia stream through a control server or gateway, which routes requests to the multimedia servers, and the client receives the stream directly from a selected (primary) server. The client automatically detects load imbalances and/or failures (complete or partial) and dynamically switches to a secondary server in order to continue receiving the real-time multimedia stream with minimal disruption, while maintaining a balanced load across multiple servers in a distributed network environment. The determination can be made based on: the received bit or frame rate (for video); a bit rate or sample rate (for audio); monitoring a delivery rate or for packets arriving out of order: for example, using packet numbering mechanisms available in TCP; sequence numbering or time stamp capabilities of RTP (in combination with the User Datagram Protocol (UDP)). In any case, the determination could be based on the rate measurement or monitoring mechanism falling below (or exceeding) some threshold. Alternately, the primary server or the control server could send an explicit distress, or switch signal to the client. An explicit signal can be used, for example, to switch clients in phases with minimal disruption.
Various systems and methods for communication over the Internet, such as by using intermediate nodes, are described in U.S. Patent Application Publication No. 2015/0067819 to Shribman et al., entitled: “System and Method for Improving Internet Communication by Using Intermediate Nodes”, which is incorporated in its entirety for all purposes as if fully set forth herein.
QoE. Quality of Experience (QoE, QoX or simply QX) is a measure of a customer experiences with a service (web browsing, phone call, TV broadcast, call to a Call Center), which focuses on the entire service experience, and is a more holistic evaluation than the more narrowly focused user experience (focused on a software interface) and customer-support experience (support focused). QoE looks at a vendor or purveyor offering from the standpoint of the customer or end user, and provides an assessment of human expectations, feelings, perceptions, cognition and satisfaction with respect to a particular product, service or application. The QoE metric is often measured at the end devices and can conceptually be seen as the remaining quality after the distortion introduced during the preparation of the content and the delivery through the network until it reaches the decoder at the end device. There are several elements in the video preparation and delivery chain, where some of them may introduce distortion that cause the degradation of the content, and several elements in this chain can be considered as “QoE relevant” for video services. These are the encoding system, transport network, access network, home network, and end device.
The concept of QoE in engineering is also known as Perceived Quality of Service (PQoS), in the sense of the QoS as it is finally perceived by the end-user. The evaluation of the PQoS for audiovisual content will provide a user with a range of potential choices, covering the possibilities of low, medium or high-quality levels. Moreover, the PQoS evaluation gives the service provider and network operator the capability to minimize the storage and network resources by allocating only the resources that are sufficient to maintain a specific level of user satisfaction. Another approach for measuring QoE for a video content is using a referenceless analysis where the QoE is not measured comparing an original video to a delivered one, but by trying to detect artifacts such as blockiness, blur, or jerkiness directly in the video. QoE is further described in an April 2012 IEEE Communications Magazine (01630-6804/12) article entitled: “Toward Total Quality of Experience: A QoE Model in a Communication Ecosystem”, which is incorporated in its entirety for all purposes as if fully set forth herein.
Timestamp. A timestamp is a sequence of characters or encoded information identifying when a certain event occurred, usually giving date and time of day, sometimes accurate to a small fraction of a second, and also refers to digital date and time information attached to the digital data. For example, computer files contain timestamps that tell when the file was last modified, and digital cameras add timestamps to the pictures they take, recording the date and time the picture was taken. A timestamp is typically the time at which an event is recorded by a computer, not the time of the event itself. In many cases, the difference may be inconsequential—the time at which an event is recorded by a timestamp (e.g., entered into a log file) should be close to the time of the event. Timestamps are typically used for logging events or in a Sequence of Events (SOE), in which case, each event in the log or SOE is marked with a timestamp. In a file system such as a database, timestamp commonly mean the stored date/time of creation or modification of a file or a record. The ISO 8601 standard standardizes the representation of dates and times which are often used to construct timestamp values, and IETF RFC 3339 defines a date and time format for use in Internet protocols using the ISO 8601 standard representation.
Geolocation. IP-based geolocation (commonly known as geolocation) is a mapping of an IP address (or MAC address) to the real-world geographic location of a computing device or a mobile device connected to the Internet. The IP address based location data may include information such as country, region, city, postal/zip code, latitude, longitude, or Timezone. Deeper data sets can determine other parameters such as domain name, connection speed, ISP, Language, proxies, company name, US DMA/MSA, NAICS codes, and home/business classification. The geolocation is further described in the publication entitled: “Towards Street-Level Client-Independent IP Geolocation” by Yong Wang et al., downloaded from the Internet on July 2014, and in an Information Systems Audit and Control Association (ISACA) 2011 white paper entitled: “Geolocation: Risk, Issues and Strategies”, which are both incorporated in their entirety for all purposes as if fully set forth herein. There are a number of commercially available geolocation databases, such as a web-site http://www.ip2location.com operated by Ip2location.com headquartered in Penang, Malaysia, offering IP geolocation software applications, and geolocation databases may be obtained from IpInfoDB operating web-site http://ipinfodb.com, and by Max Mind, Inc., based in Waltham, Mass., U.S.A, operating the web-site www.maxmind.com/en/home.
Further, the W3C Geolocation API is an effort by the World Wide Web Consortium (W3C) to standardize an interface to retrieve the geographical location information for a client-side device. It defines a set of objects, ECMA Script standard compliant, executing in the client application, give the client's device location through the consulting of Location Information Servers, which are transparent for the Application Programming Interface (API). The most common sources of location information are IP address, Wi-Fi and Bluetooth MAC address, radio-frequency identification (RFID), Wi-Fi connection location, or device Global Positioning System (GPS) and GSM/CDMA cell IDs. The location is returned with a given accuracy depending on the best location information source available. The W3C Recommendation for the geolocation API specifications draft dated Oct. 24, 2013, is available from the web-site http://www.w3.org/TR/2013/REC-geolocation-API-20131024. Geolocation-based addressing is described in U.S. Pat. No. 7,929,535 to Chen et al., entitled: “Geolocation-based Addressing Method for IPv6 Addresses”, and in U.S. Pat. No. 6,236,652 to Preston et al., entitled: “Geo-spacial Internet Protocol Addressing”, and in U.S. Patent Application Publication No. 2005/0018645 to Mustonen et al., entitled: “Utilization of Geographic Location Information in IP Addressing”, which are all incorporated in their entirety for all purposes as if fully set forth herein.
In consideration of the foregoing, it would be an advancement in the art to provide an improved functionality method and system that is simple, secure, anonymous, and cost-effective, providing improved CAPEX (Capital Expenditure) or OPEX (Operational Expenditures) savings, load-balanced, redundant, reliable, provide lower CPU and/or memory usage, enable pipelining of requests and responses, reduce network congestion, using low delivery rate sources or servers, lower start-up time, easy to use, reduce latency, faster, has a minimum part count, minimum hardware, and/or uses existing and available components, protocols, programs and applications for providing better quality of service, overload avoidance, better or optimal resources allocation, better communication and additional functionalities, a better user experience, or improved QoE.